Automated preparation and submission of electronic registration

ABSTRACT

A system for automated preparation and submission of electronic registration may obtain a pre-existing entity identifier that had been previously used by an electronic system of at least one authority entity to identify a primary entity. The system may electronically associate the pre-existing entity identifier with the primary entity and use it to perform automated actions to electronically collect one or more support content from the Internet or other sources regarding the primary entity. The system may electronically identify data from the support content relevant to the electronic registration and electronically extract the identified data from the support content. The system may also electronically verify the extracted data before electronically generating and submitting the electronic registration based on the extracted data. An adaptive UI may be automatically modified in response to a determination whether to electronically present a query via the adaptive UI for the supplemental data.

TECHNICAL FIELD

The technical field relates to computer networks, and particularly to the technology of automated networked systems for preparation and submission of electronic documents and registration.

BRIEF SUMMARY

The present description gives instances of computer systems, devices and storage media that may store programs and methods. An example embodiment includes an automated electronic registration preparation and submission system that electronically generates, via a registration engine, an electronic registration based on extracted data. The system may electronically initiate a process to collect data via a graphical user interface (GUI) to facilitate automated preparation of an electronic registration before initiating a process to remit resources from a first entity (e.g., primary entity) to one or more recipient entities based on relationship instances between the primary entity and a plurality of secondary entities.

The system may obtain a pre-existing entity identifier that had been previously used by an electronic system of at least one third party authority entity to identify a primary entity. The system may electronically associate the pre-existing entity identifier with the primary entity and use it to perform automated actions to electronically collect support content from the Internet or other sources regarding the primary entity to facilitate automated preparation of the electronic registration document. The system may then electronically identify data from the support content relevant to the electronic registration and electronically extract the identified data from the support content in response to electronically identifying the data. The system may also electronically verify the extracted data before electronically generating and submitting the electronic registration based on the extracted data.

Such processing and generating the registration may be performed by the registration engine for hundreds or thousands of clients via hundreds or thousands of remote client devices over the network simultaneously or concurrently (which is impossible to do in the human mind) to provide more accurate and efficient computer network operations for electronic document generation for various systems on the network, including the client devices and devices of systems on which the electronic registrations are electronically submitted, thus improving the technology of computer networks and the technology of electronic document generation and registration.

In particular, such simultaneous and/or concurrent electronic generating and submitting of the registration being performed by the registration engine for hundreds or thousands of clients via hundreds or thousands of remote client devices over the network increases the speed at which the electronic services are provided (as opposed to the devices waiting for them to be performed serially). This reduces data flow over the computer network by avoiding the client devices having to resend requests over the network to perform the electronic services and provide updated data due to lag times that would otherwise be experienced by the client devices between when the original request was sent and the electronic operations are able to be performed. Thus, the systems and methods described herein for automated actions for automated preparation and submission of electronic registration improves the functioning of computer or other hardware, such as by reducing the processing, storage, and/or data transmission resources needed to perform various tasks, including preparation and submission of electronic registration, thereby enabling the tasks to be performed by less capable, capacious, and/or expensive hardware devices, and/or be performed with less latency, and/or preserving more of the conserved resources for use in performing other tasks or additional instances of the same task.

In some embodiments, user input may indicate where the client or associated entity is from or located. Based on this user input, the digital rules may be electronically consulted to automatically choose which web site or data source the system has to interact with to obtain certain information for the registration process. In various embodiments, the digital rules may be electronically consulted based upon modifiable workflow configurations.

An adaptive user interface (UI) to the system for processing registrations for registering with one or more remote systems may be presented on a client device. In an example embodiment, before electronically generating the registration based on the extracted data, the registration engine electronically determines, based on the extracted data, whether to electronically present a query via the adaptive UI for supplemental data regarding the entity associated with the client device to facilitate automated preparation of the electronic registration. The registration engine may automatically modify the adaptive UI in response to the determination whether to electronically present a query via the adaptive UI for the supplemental data. The registration engine may electronically present the query via the adaptive UI for the supplemental data. The registration engine may electronically receive the supplemental data over the network via the adaptive UI in response to electronically presenting the query via the adaptive UI for the supplemental data and then electronically verify the supplemental data.

As shown above and in more detail throughout the present disclosure, the present disclosure provides technical improvements in computer networks and existing computerized systems to facilitate accuracy, efficiency and speed of computing resources to perform automated electronic registration preparation and submission and electronic document generation.

These and other features and advantages of the claimed invention will become more readily apparent in view of the embodiments described and illustrated in this specification, namely in this written specification and the associated drawings.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The components in the drawings are not necessarily drawn to scale relative to each other. Like reference numerals designate corresponding parts throughout the several views.

FIG. 1 is a diagram showing sample aspects of embodiments of the present disclosure.

FIG. 2 is a diagram that repeats some of the digital main rules of FIG. 1 in more detail, and juxtaposes them with a flowchart portion for a sample method of how it may be recognized that conditions of a certain digital main rule can be met for its consequent to be applied, all according to embodiments of the present disclosure.

FIG. 3A is a flowchart for illustrating a sample method according to embodiments of the present disclosure.

FIG. 3B is a flowchart for illustrating a sample method, useful in the method of FIG. 3A, for electronically receiving and verifying supplemental data according to embodiments of the present disclosure.

FIG. 4 is a block diagram showing additional components of sample computer systems according to embodiments of the present disclosure.

FIG. 5 is a diagram of sample aspects for describing operational examples and use cases of embodiments of the present disclosure that are improvements in automated computerized systems.

FIG. 6 is a block diagram illustrating an example Workflow-as-a-Service (WFaaS) component of an example online software platform for registering with a tax authority or for filing a tax return that is an improvement in automated computerized systems, according to various embodiments of the present disclosure.

FIG. 7 is a flowchart for illustrating a sample method for electronically generating a registration form for registering with a value added taxation (VAT) tax authority or for filing a VAT tax return according to an embodiment of the present disclosure.

FIG. 8 is a flowchart for illustrating a sample method for electronically generating a registration form for registering with a VAT tax authority or for filing a VAT tax return according to another embodiment of the present disclosure.

FIG. 9 is a flowchart for illustrating a sample method for electronically generating and filing a VAT tax return based on a registration form according to various embodiments of the present disclosure.

FIG. 10 is a flowchart for illustrating a sample method for electronically requesting and verifying missing data to generate a registration form for registering with a VAT tax authority or for filing a VAT tax return according to an embodiment of the present disclosure.

FIG. 11 is a sample view of a User Interface (UI) for an online software platform (OSP) utilizing a customer identifier in a process of generating a registration form for registering with a VAT tax authority or for filing a VAT tax return according to an embodiment of the present disclosure.

FIG. 12 is a sample view of a UI for an online software platform (OSP) presented to a user for collecting business information for generating a registration form for registering with a VAT tax authority or for filing a VAT tax return according to an embodiment of the present disclosure.

FIG. 13 is a sample view of a UI for an online software platform (OSP) presented to a user for indicating which tasks still need to be completed in a process for generating a registration form for registering with a VAT tax authority or for filing a VAT tax return according to an embodiment of the present disclosure.

FIG. 14 is a sample view of a UI for an online software platform (OSP) presented to a user for verification of the user's identity in a process for generating a registration form for registering with a VAT tax authority or for filing a VAT tax return according to an embodiment of the present disclosure.

FIG. 15 is a sample view of a UI for an online software platform (OSP) presented to a user showing an identification document uploaded by the user for verification of the user's identity in a process for generating a registration form for registering with a VAT tax authority or for filing a VAT tax return according to an embodiment of the present disclosure.

FIG. 16 is a sample view of a UI for an online software platform (OSP) presented to a user for indicating certain tasks have been completed in a process for generating a registration form for registering with a VAT tax authority or for filing a VAT tax return according to an embodiment of the present disclosure.

FIG. 17 is a sample view of a UI for an online software platform (OSP) presented to a user for the user to verify extracted data in a process for generating a registration form for registering with a VAT tax authority or for filing a VAT tax return according to an embodiment of the present disclosure.

FIG. 18 is a sample view of a UI for an online software platform (OSP) presented to a user for electronically completing a power of attorney in a process for generating a registration form for registering with a VAT tax authority or for filing a VAT tax return according to an embodiment of the present disclosure.

FIG. 19 is a sample view of a UI for an online software platform (OSP) presented to a user for electronically downloading documents and then uploading signed documents, such as a power of attorney, in a process for generating a registration form for registering with a VAT tax authority or for filing a VAT tax return according to an embodiment of the present disclosure.

FIG. 20 is a sample view of a UI for an online software platform (OSP) presented to a user when an uploaded image is not clear, such as that of a power of attorney or identification document, in a process for generating a registration form for registering with a VAT tax authority or for filing a VAT tax return according to an embodiment of the present disclosure.

FIG. 21 is a sample view of a UI for an online software platform (OSP) presented to a user when an uploaded image is clear, such as that of a power of attorney, in a process for generating a registration form for registering with a VAT tax authority or for filing a VAT tax return according to an embodiment of the present disclosure.

FIG. 22 is a sample view of a UI for an online software platform (OSP) presented to the user indicating the status of signatures needed in each different jurisdiction for which registration is being applied, in a process for generating a registration form for registering with a VAT tax authority or for filing a VAT tax return according to an embodiment of the present disclosure.

FIG. 23 is a sample view of an internal adaptive UI of an online software platform (OSP) for processing registrations for registering with a VAT tax authority or for filing a VAT tax return according to an embodiment of the present disclosure.

FIG. 24 is a block diagram showing a system for generating a registration form for registering with a VAT tax authority or for filing a VAT tax return and for filing VAT tax returns according to an embodiment of the present disclosure.

FIGS. 25A through 25D comprise a swimlane diagram including a flowchart for illustrating which system component may perform different operations in a sample process for electronically generating a registration form for registering with a value added taxation (VAT) tax authority or for filing a VAT tax return according to an embodiment of the present disclosure.

DETAILED DESCRIPTION

The description that follows includes systems, methods, techniques, instruction sequences, and computing machine program products that embody illustrative embodiments of the disclosure. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide an understanding of various embodiments of the inventive subject matter. It will be evident, however, that embodiments of the inventive subject matter may be practiced without these specific details. In general, well-known structures and methods associated with underlying technology have not been shown or described in detail to avoid unnecessarily obscuring descriptions of the preferred embodiments. Additionally, the various embodiments may be methods, systems, media, or devices. Accordingly, the various embodiments may be entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects.

FIG. 1 is a diagram showing sample aspects of embodiments of the present disclosure. In particular, in an example embodiment, an automated electronic registration preparation and submission system 102 electronically generates, via the registration engine 183 of the OSP 198, an electronic registration based on extracted data. The OSP 198 may electronically initiate a process to collect data via a graphical user interface (GUI) to facilitate automated preparation of an electronic registration before initiating a process to remit resources from a first entity (e.g., primary entity 193) to one or more recipient entities based on relationship instances between the primary entity 193 and a plurality of secondary entities (not shown). The OSP 198 may obtain a pre-existing entity identifier that had been previously used by an electronic system of at least one authority entity to identify the primary entity 193. The OSP 198 may electronically associate the pre-existing entity identifier with the primary entity 193 and use it to perform automated actions to electronically collect support content from the Internet or other sources, including internal content of the OSP 198 (e.g., via a communication network 188) regarding the primary entity 193 to facilitate automated preparation of the electronic registration document. The OSP 198 may then electronically identify data from the support content relevant to the electronic registration and electronically extract the identified data from the support content in response to electronically identifying the data. In an example embodiment, the OSP 198 may also electronically verify the extracted data before electronically generating the electronic registration based on the extracted data.

A thick line 115 separates this diagram, although not completely or rigorously, into a top portion and a bottom portion. Above the line 115 the emphasis is mostly on entities, components, their relationships, and their interactions, while below the emphasis is mostly processing of data that takes place often within one or more of the components above the line 115.

Above the line 115, a sample computer system 195 according to embodiments is shown. The computer system 195 has one or more processors 194 and a memory 130. The memory 130 stores programs 131 and data 138. The one or more processors 194 and the memory 130 of the computer system 195 thus implement a registration engine 183. The data 138 may include, among other types of content, data associated with user 192, the primary entity 193, and/or relationship instances or resources associated with user 192 and/or the primary entity 193. Additional implementation details for the computer system 195 are given later in this document.

The computer system 195 can be located in “the cloud.” In fact, the computer system 195 may optionally be implemented as part of an online software platform (OSP) 198. The OSP 198 can be configured to perform one or more predefined services, for example, via operations of the registration engine 183. Such services can be, but are not limited to: searches, determinations, computations, verifications, notifications, the transmission of specialized information, including data that performs electronic registrations, effectuates payments or remits resources, the generation and transmission of documents, online accessing of other systems to effect registrations, and so on, including what is described in this document. Such services can be provided as a Software-as-a-Service (SaaS) and be configurable via a Workflow-as-a-Service (WFaaS) system integrated with and/or coupled to the OSP 198.

A user 192 may be standalone. The user 192 may use a computer system 190 that has a screen 191, on which User Interfaces (Uis) may be shown. Additional sample implementation details for the computer system 190 are given later in this document. In embodiments, the user 192 and the computer system 190 are considered part of a primary entity 193, which can be referred to also merely as entity, customer or client. In such instances, the user 192 can be an agent of the entity 193, and even within a physical site of the entity 193, although that is not necessary. In embodiments, the computer system 190 or other device of the user 192 or the entity 193 are client devices for the computer system 195.

The computer system 190 may access the computer system 195 via the communication network 188, such as the Internet. In particular, the entities and associated systems of FIG. 1 may communicate via physical and logical channels of the communication network 188. For example, information may be communicated as data using the Internet Protocol (IP) suite over a packet-switched network such as the Internet or other packet-switched network, which may be included as part of the communication network 188. The communication network 188 may include many different types of computer networks and communication media including those utilized by various different physical and logical channels of communication, now known or later developed. Non-limiting media and communication channel examples include one or more, or any operable combination of: fiber optic systems, satellite systems, cable systems, microwave systems, asynchronous transfer mode (“ATM”) systems, frame relay systems, radio frequency (“RF”) systems, telephone systems, cellular systems, other wireless systems, and the Internet. In various embodiments the communication network 188 can be or include any type of network, such as a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a private or public wireless cellular network (e.g., a fifth generation (5G) wireless network) or the Internet.

Downloading or uploading may be permitted from one of these two computer systems (computer system 190 and computer system 195) to the other, and so on. Such accessing can be performed, for instance, with manually uploading files, like images or spreadsheet files, etc. Such accessing can also be performed automatically as shown in the example of FIG. 1 . The computer system 190 and the computer system 195 may exchange requests and responses with each other. Such can be implemented with a number of architectures.

In one such architecture, a device remote to the registration engine 183, such as computer system 190, may have a certain application (not shown) and a connector (not shown) that is a plugin that sits on top of that certain application. The connector may be able to fetch from the remote device the details required for the service desired from the OSP 198, form an object or payload 134, and then send or push a request 184 that carries the payload 134 to the registration engine 183 via a service call. The registration engine 183 may receive the request 184 with the payload 134. The registration engine 183 may then apply digital rules 170 to the payload 134 to obtain, collect, extract, identify, associate and/or verify data; generate an electronic form; perform an electronic registration 179, determine a requested resource and/or form a payload 137 that is an aspect of such operations, the electronic registration 179 and/or the resource. The registration engine 183 may then push, send, or otherwise cause to be transmitted a response 187 that carries the payload 137 to the connector. The connector reads the response 187, and forwards the payload 137 to the certain application.

In an alternative such architecture, a device remote to the registration engine 183, such as computer system 190, may have a particular application (not shown). In addition, the computer system 195 may implement a REST (Representational State Transfer) API (Application Programming Interface) (not shown). REST or RESTful API design is designed to take advantage of existing protocols. While REST can be used over nearly any protocol, it usually takes advantage of HTTP (Hyper Text Transfer Protocol) when used for Web APIs. This alternative architecture enables the primary entity 193 to directly consume a REST API from their particular application, without using a connector. The particular application of the remote device may be able to fetch internally from the remote device the details required for the service desired from the OSP 198, and thus send or push the request 184 to the REST API. In turn, the REST API talks in the background to the registration engine 183. Again, the registration engine 183 may perform the electronic registration 179, and sends an aspect of performing the electronic registration 179 back to the REST API or to an API of another device or system. In turn, the REST API sends the response 187 that has the payload 137 to the particular application.

Moreover, in some embodiments, data from the computer system 190 and/or from the computer system 195 may be stored in an Online Processing Facility (OPF) 189 that can run software applications, perform operations, and so on. In such embodiments, requests and responses may be exchanged with the OPF 189, downloading or uploading may involve the OPF 189, and so on. In such embodiments, the computer system 190 and any devices of the OPF 189 can be considered to be remote devices, at least from the perspective of the computer system 195.

In some instances, the user 192 or the primary entity 193 may have instances of relationships with secondary entities (not shown). For example, communication between the primary entity 193 and a secondary entity may be made over network 188. In some instances, the user 192, the primary entity 193 may have data about one or more secondary entities, for example via relationship instances of the user 192 or primary entity with the secondary entity. Also, the secondary entity may have data about the primary entity 193, for example via relationship instances of the user 192 or primary entity 193 with the secondary entity. The primary entity 193 and/or the secondary entity may be referred to as simply entities. One of these entities may have one or more attributes. Such an attribute of such an entity may be any one of its name, type of entity, a physical or geographical location such as an address, types of goods or services sold by the entity, whether the entity is an online marketplace, a contact information element, an affiliation, a characterization of another entity, a characterization by another entity, an association or relationship with another entity (general or specific instances), an asset of the entity, a document of the entity, a declaration by or on behalf of the entity, and so on.

In embodiments, the computer system 195 receives one or more datasets. A sample received dataset 135 is shown below the line 115. The dataset 135 may be received by the computer system 195 in a number of ways. In some embodiments, one or more requests may be received by the computer system 195 via a network. In this example, a request 184 is received by the computer system 195 via the network 188. The request 184 has been transmitted by the remote computer system 190. The received one or more requests can carry payloads. In this example, the request 184 carries payload 134. In such embodiments, the one or more payloads may be parsed by the computer system 195 to extract the dataset. In this example, the payload 134 can be parsed by the computer system 195 to extract the dataset 135. In this example the single payload 134 encodes the entire dataset 135, but that is not required. In fact, a dataset can be received from the payloads of multiple requests. In such cases, a single payload may encode only a portion of the dataset. And, of course, the payload of a single request may encode multiple datasets. Additional computers may be involved with the network 188, some beyond the control of the user 192 or OSP 198, and some within such control.

The dataset 135 has values that can be numerical, alphanumeric, Boolean, and so on, as needed for what the values characterize. For example, an identity value ID may indicate an identity of the dataset 135, so as to differentiate it from other such datasets. At least one of the values of the dataset 135 may characterize an attribute of a certain one of entity 193 and a secondary entity, as indicated by arrow 199. (It should be noted that the arrows 199 describe a correspondence, but not the journey of data in becoming the received dataset 135.) For instance, a value D1 may be the name or other identifier of the certain entity, a value D2 may be for relevant data of the entity, and so on. Plus, an optional value B1 may be a numerical base value for an aspect of the dataset, and so on. The aspect of the dataset may be the aspect of the value that characterizes the attribute, an aspect of the reason that the dataset was created in the first place, a pre-existing entity identifier, an attribute of a relationship instance between the primary entity 193 and one or more secondary entities, an indication of an identity or other characteristic of the primary entity 193, support content, data relevant to an electronic registration of the primary entity 193, and so on.

The dataset 135 may further have additional such values, as indicated by the horizontal dot-dot-dot to the right of the dataset 135. In some embodiments, each dataset, such as dataset 135, corresponds to one relationship instance or one or more electronic registrations. In some embodiments, the dataset 135 may correspond to a plurality of relationship instances or registrations and include such respective values for each respective relationship instance of the plurality of relationship instances or for each respective registration of the plurality of relationship registrations. In some embodiments, the dataset 135 has values that characterize attributes of each of the primary entity 193 and the secondary entity, but that is not required. In some embodiments, the primary entity 193 may be the secondary entity and communications described herein such as the request 184 and response 187 may be additionally or instead between the secondary entity and the computer system 195.

In embodiments, stored digital rules 170 may be accessed by the computer system 195. These rules 170 are digital in that they are implemented for use by software. For example, these rules 170 may be implemented within programs 131 and data 138. The data portion of these rules 170 may alternately be implemented in memories in other places, which can be accessed via the network 188. These rules 170 may be accessed responsive to receiving a dataset, such as the dataset 135.

The digital rules 170 may include main rules, which can thus be accessed by the computer system 195. In this example, three sample digital main rules are shown explicitly, namely M_RULE5 175, M_RULE6 176, and M_RULE7 177. In this example, the digital rules 170 also include digital precedence rules P_RULE2 172 and P_RULE3 173, which can thus be further accessed by the computer system 195. The digital rules 170 may include additional rules and types of rules, as suggested by the vertical dot-dot-dots.

In embodiments, a certain one of the digital main rules may be identified from among the accessed stored rules by the computer system 195. In particular, values of the dataset 135 can be tested, according to arrows 171, against logical conditions of the digital main rules, as described later in this document. In this example, the certain main rule M_RULE6 176 is thus identified, which is indicated also by the beginning of an arrow 178 that is described in more detail later in this document. Identifying may be performed in a number of ways, and depending on how the digital main rules are implemented. An example is now described.

Referring now also to FIG. 2 , some of the digital main rules of digital rules 170 are repeated from FIG. 1 in more detail. In addition, according to an arrow 270, these digital main rules are shown juxtaposed with a flowchart portion 200. In embodiments, some of the digital main rules can be expressed in the form of a logical “if-then” statement, such as: “if P then Q”. In such statements, the “if” part, represented by the “P”, is called the condition, and the “then” part, represented by the “Q”, is called the consequent. Therefore, at least some of the digital main rules include respective conditions and respective consequents associated with the respective conditions, respectively. And, for a certain digital main rule, if its certain condition P is met, then its certain consequent Q is what happens or becomes applied. One or more of the digital rules 170 may have more than one conditions P that both must be met, and so on. And some of these digital rules 170 may be searched for, and grouped, according first to one of the conditions, and then the other. In this example, the digital main rules M_RULE5 175, M_RULE6 176, and M_RULE7 177 of FIG. 1 , include respective conditions CN5, CN6, CN7, and respective consequents CT5, CT6, CT7 associated with the respective conditions CN5, CN6, CN7, respectively.

In embodiments, therefore, identifying is performed by recognizing, by the computer system 195, that a certain condition of a certain one of the accessed digital main rules is met by one or more of the values of the dataset. An example of the operations of recognizing that a condition is met and thus identifying an applicable rule is shown by flowchart portion 200 of FIG. 2 . According to successive decision diamonds 285, 286, 287, it is determined whether or not conditions CN5, CN6, CN7 are met by at least one of the values of the dataset, respectively. If the answer is NO, then execution may proceed to the next diamond. If the answer is YES then, according to operations 295, 296, 297, it is further determined that the respective consequents CT5, CT6, CT7 are to be applied, and then execution may proceed to the next diamond in the flowchart portion. A consequent that is to be applied could be, for example, flagged as TRUE.

From what was mentioned in connection with FIG. 1 , the certain M_RULE6 176 was thus identified. With reference to FIG. 2 , the identification may have happened at operation 286 of the flowchart portion 200, at which time it was recognized that condition CN6 was met by a value of the dataset 135. This made: the condition CN6 be the certain condition, the digital main rule M_RULE6 176 be the certain digital main rule, and the consequent CT6 be the certain consequent of the certain digital main rule M_RULE6 176. And the certain consequent CT6 is associated with the certain condition CN6, since both are included by the certain digital main rule 176. Therefore, according to operation 296, consequent CT6 is what happens or becomes applied, as described below.

A number of examples are possible for how to recognize that a certain condition of a certain digital rule is met by at least one of the values of the dataset. For instance, the certain condition could define a boundary of a region that is within a space. The region could be geometric, and be within a larger space and may include political boundaries. For example, the region could be geographic, within the space of a city, a county, a state, a country, a continent or the earth. The boundary of the region could be defined in terms of numbers according to a coordinate system within the space. In the example of geography, the boundary could be defined in terms of groups of longitude and latitude coordinates. In such embodiments, the certain condition could be met responsive to the characterized attribute of the dataset being in the space and within the boundary of the region instead of outside the boundary. For instance, the attribute could be a location of the entity, and the one or more values of the dataset 135 that characterize the location could be one or more numbers or an address, or longitude and latitude. The condition can be met depending on how the one or more values compare with the boundary. For example, the comparison may reveal that the location is in the region instead of outside the region. The comparison can be made by rendering the characterized attribute in units comparable to those of the boundary. For example, the characterized attribute could be an address that is rendered into longitude and latitude coordinates, and so on.

The above embodiments are only examples, and not limiting. For instance, the example of FIG. 2 suggests that there is a one-to-one correspondence of the conditions with the associated consequents, but that is not necessary. In fact, a single consequent may be associated with two or more conditions, and two or more consequents may be associated with a single condition. Of course, all such can be shown as additional rules, with groups of them having the same condition or consequent.

For another instance, once it is determined that a consequent is to be applied, execution may even exit the flowchart portion 200. Or, as shown, it may be determined that more than one of the digital main rules is to be applied. In particular, operation 286 may give the answer YES such that consequent CT6 is to be applied, and operation 287 may also give the answer YES such that consequent CT7 is to be applied.

Where more than one of the digital main rules are found that could be applied, there are additional possibilities. For instance, the computer system 195 of FIG. 1 may further access at least one stored digital precedence rule, such as P_RULE2 172 or P_RULE3 173. Accordingly, the certain digital main rule may be thus identified also from the digital precedence rule. In particular, the digital precedence rule may decide which one or more of the digital main rules is to be applied. To continue the previous example, if a value of the dataset 135 that characterizes a location, and the location is within multiple overlapping regions according to multiple rules, the digital precedence rule may decide that all of them are to be applied, or less than all of them are to be applied. Equivalent embodiments are also possible, where digital precedence rules are applied first to limit the iterative search of the flowchart portion 200, so as to test the applicability of fewer than all the rules according to arrows 171.

Another example for how to recognize that a certain condition of a certain digital rule is met by at least one of the values of the dataset is that the certain condition could be regarding whether there exists an entity identifier associated with the values of the dataset associated with the primary entity. In such embodiments, the certain condition could be met responsive to there being an entity identifier associated with the values of the dataset associated with the primary entity. For example, responsive to instances in which there is an entity identifier associated with the values of the dataset associated with the primary entity, the system 102 may use at least the entity identifier to perform automated actions to electronically collect one or more support content from the Internet regarding the primary entity to facilitate automated preparation of the electronic registration document.

As such, in some embodiments, the registration is performed based on determinations and/or a computations using such collected support content. In the example of FIG. 1 , a registration 179 is produced based on the dataset 135, by the computer system 195 applying the certain M_RULE6 176, and in particular its certain consequent CT6, as indicated by the arrow 178. In fact, sometimes applying the consequent is more simply stated as “applying the rule”.

As mentioned above, in some embodiments two or more digital main rules may be applied. For instance, referring again to FIG. 1 , the computer system 195 may recognize that an additional condition of an additional one of the accessed digital main rules 170 is met by at least one of the values of the dataset 135. In this example there would be no digital precedence rules, or the available digital precedence rules would not preclude both the certain digital main rule and the additional digital main rule from being applied concurrently. Such an additional digital main rule would have an additional consequent.

In such embodiments, the registration may be produced by the computer system applying the certain consequent and the additional consequent. For instance, where the base value B1 is used, applying the certain consequent may include comparing the base value B1 with a first value indicated by the certain consequent, so as to compute a first result. In addition, applying the additional consequent may include comparing the base value B1 with a second value indicated by the additional consequent, so as to compute a second result. Also, the registration may be performed based on the first result and the second result.

In embodiments, a notification, such as notification 136 of FIG. 1 , can be caused to be transmitted, e.g., via the network 188, by the computer system. The notification can be about an aspect of the registration 179 or process of registration. In the example of FIG. 1 , notification 136 can be caused to be transmitted by the computer system 195, for example as an answer or other response to the received dataset 135. The notification 136 can be about an aspect of the registration 179 or electronic registration process. In particular, the notification 136 may inform about the aspect of the registration 179, namely that it has been performed, its status, and so on. Of course, the planning should be that the recipient of the notification 136 understands what it is being provided.

The notification 136 can be transmitted to one of an output device and another device. The output device may be the screen of a local user or a remote user. The notification 136 may thus cause a desired image, message, or other such notification to appear on the screen, such as within a Graphical User Interface (GUI) and so on. The other device can be the remote device, from which the dataset 135 was received, as in the example of FIG. 1 . In particular, the computer system 195 may cause the notification 136 to be communicated by being encoded as payload 137, which is carried by response 187. The response 187 may be transmitted via the network 188 responsive to the received request 184. The response 187 may be transmitted to the computer system 190, or to OPF 189, and so on. As such, the other device can be the computer system 190, or the OPF 189, or the screen 191 of the user 192, and so on. In this example, the single payload 137 encodes the entire notification 136, but that is not required. Similarly, with what is written above about encoding datasets in payloads, the notification 136 instead may be provided via two or more payloads, or in other cases the notification 136, and at least one other notification, may be included in the same single payload. Along with the aspect of the registration 179, it can be advantageous to embed in the payload 137 the identity value (ID) and/or one or more values of the dataset 135. This will help the recipient correlate the response 187 to the request 184, and therefore match the received aspect of the registration 179 as the answer or other response to the appropriate dataset.

In an example embodiment, there may be a plurality of relationship instances between the primary entity 193 and one or more secondary entities. Each relationship instance may be associated with one or more respective domains of a plurality of domains. For example, a resource associated with the relationship instance 197 may be received by the primary entity. In various embodiments, a domain may be a region defined by a boundary as discussed above or may be an entity representing or otherwise associated with the region. For example, the region could be geographic, within the space of a city, a county, a state, a country, a continent or the earth. The plurality of relationship instances may result in a requirement that an electronic reporting document or other datasheet associated with the primary entity 193 be prepared regarding an amount of resources due to one or more of the plurality of domains, that the document be sent to one or more of the plurality of domains and that resources possibly be remitted to one or more of the plurality of domains. It may be a condition that a registration is performed of the primary entity with one or more of the plurality of domains such that the document may be sent to one or more of the plurality of domains and that resources possibly be remitted to one or more of the plurality of domains. A domain as used herein may refer to a geographic area or to one or more authorities (or computerized systems controlled by such authorities) that set or define rules or digital rules for such a geographic area or domain as described herein. The OSP 198 may perform or facilitate such electronic actions.

For example, in one embodiment, primary entity 193 may have a relationship instance with secondary entity and that particular relationship instance may be associated with one or more domains. The association of the relationship instance with the one or more domains may be based on a variety of characteristics including, but not limited to: a relationship of one or more of the primary entity and secondary entity with the particular domain; a location of one or more of the primary entity and secondary entity within or associated with the particular domain; a region or location associated with one or more of the primary entity and secondary entity being within or associated with the particular domain; a previous relationship of one or more of the primary entity and secondary entity with the particular domain; a location of items associated with one or more of the primary entity and secondary entity within the particular domain; a number of relationships of one or more of the primary entity and secondary entity with the particular domain; a transfer of items associated with one or more of the primary entity and secondary entity to or from an entity within or associated with the particular domain; a transfer of data associated with one or more of the primary entity and secondary entity to or from an entity within or associated the particular domain, etc. The existence or identification of the relationship instance and/or one or more characteristics of the relationship instance may be defined or represented by values of dataset 135.

In some embodiments, for each relationship instance of the plurality of relationship instances, the OSP 198 electronically identifies a rate to calculate an amount of resource due to one or more respective domains associated with the relationship instance based on a source of a resource received for the relationship instance, a type of relationship instance and the one or more respective domains. For example, the primary entity 193 may send request 184 to the computer system 195 of OSP 198 for services that facilitate remitting resources due to one or more respective domains. The request 184 may include the existence or identification of the relationship instance and/or one or more characteristics of the relationship instance as part of payload 134. The registration engine 183 may then apply digital rules 170 to the relationship instance and/or one or more characteristics of the relationship instance to identify or otherwise determine the rate to calculate an amount of resource due to one or more respective domains associated with the relationship instance.

For example, digital precedence rule P_RULE2 172 may decide that rule M_RULE5 175 is to be applied when a particular condition is met. Digital precedence rule P_RULE2 172 may include a condition that indicates if particular data is identified from support content relevant to the electronic registration, then rule M_RULE5 175 is to be applied. The registration engine 183 may determine that the condition is met due to one or more values of dataset 135 indicating particular data is identified from support content relevant to the electronic registration. Thus, as a consequent of precedence rule P_RULE2 172, the registration engine 183 applies rule M_RULE5 175. Rule M_RULE5 175 may include a condition CN5 that indicates if particular data is identified from support content relevant to the electronic registration, then, as consequent CT5, the identified data is to be extracted from the support content.

Referring again to FIG. 2 , at decision diamond 285 it is determined that the condition CN5 is met (i.e., that particular data is identified from support content relevant to the electronic registration) and thus, the identified data is to be extracted from the support content. Thus, by applying digital rules 170, the registration engine 183 electronically extracts the identified data from the support content in response to the electronically identifying the data. In some embodiments, this extracted data may be included by the registration engine 183 as part of the resulting registration 179 and/or notification 136. The registration engine 183 may then form a payload 137 that is an aspect of the registration 179, and then push, send, or otherwise cause to be transmitted a response 187 that carries the payload 137 to a device remote to the registration engine 183, such as computer system 190, a device of a secondary entity or device associate with a particular domain or authority. Digital rules 170 may include multiple different digital rules for each type of relationship instance and different domains.

The registration engine 183 may also, for each domain of the plurality of domains, aggregate a total amount of resources due to the domain based on the calculated amount of resources due for each relationship instance associated with the domain and electronically prepare a reporting document indicating the total amount of resources due to the domain and an amount of resources already remitted to the domain for the plurality relationship instances. After registration, the registration engine 183, a filing engine (not shown) or another component of the OSP 198 may then push, transmit or otherwise cause to be sent the reporting document to a system of the domain via network 188 and/or the computer system 190 of the primary entity 193. For example, the prepared reporting document may comprise, be included in, or be electronically submitted in conjunction with, the resulting registration 179. The system of the domain to which the reporting document is sent may be a secondary entity accessible via network 188.

FIG. 3A is a flowchart for illustrating a sample method 300 according to embodiments of the present disclosure.

At 302, the OSP 198 electronically initiates a process to collect data via a graphical user interface (GUI) to facilitate automated preparation of an electronic registration before initiating a process to remit resources from a first entity to one or more recipient entities based on relationship instances between the first entity and a plurality of secondary entities.

At 304, the OSP 198 electronically obtains a pre-existing entity identifier that had been previously used by an electronic system of at least one authority entity to identify the first entity. In some embodiments, the authority entity is the recipient entity. For example, this may include receiving an electronic document submitted via the GUI and extracting the entity identifier from the electronic document submitted via the GUI. In some embodiments, this may include presenting a prompt via the GUI for the entity identifier and a field into which the entity identifier is able to be entered and receiving the entity identifier via the GUI from the field into which the entity identifier was entered. The OSP 198 may generate a customer identifier based on the pre-existing entity identifier to identify the first entity (e.g., primary entity 193) within a system that generates the electronic registration.

At 306, the OSP 198 electronically establishes the pre-existing entity identifier to be associated with the first entity.

At 308, the OSP 198, using at least the entity identifier, performs automated actions to electronically collect one or more support content, for example from the Internet and/or other local or remote sources, regarding the first entity to facilitate automated preparation of the electronic registration document. The OSP 198 may confer or compare internal content it may already have associated with the identifier (e.g., content stored in memory 130 previously received from the user 192 and/or other sources). For example, this internal content may include existing data regarding the primary entity already stored within a system that generates the electronic registration (e.g., the OSP 198) resulting from providing past electronic services calculating or remitting resources from the primary entity to one or more recipient entities. The support content includes one or more electronic documents. As another example, collection of the support content may include the registration engine 183 using a web crawler to go to public web sites to collect the one or more support content. In an example embodiment, using the web crawler may be in response to the OSP 198 determining the internal content and/or content provided via user 192, such as via a user interface displayed on screen 191, is incomplete or incorrect, and thus data is missing for completing the electronic registration. By combining the internal data associated with the entity identifier, if any, and crawled data from the Internet, the OSP 198 may formulate a more complete set of content to complete an accurate registration in an automated way for the user 192. The crawled data can also be used to verify or update registration data for an existing identifier. If there is any missing information (either from the internal content and/or from the content retrieved from the Internet), the OSP 198 may notify or request that from the user 192 (associated with the identifier). Registration data can be collected from at least within the OSP, crawling the Internet and/or requesting from the user 192.

At 310, the OSP 198 electronically identifies data from the one or more support content relevant to the electronic registration. For example, this may include electronically reading one or more electronic documents to identify data relevant to the electronic registration in the one or more electronic documents. In one example, the OSP 198 may use the entity identifier to identify which recipient entity and which digital rules (e.g., which of digital rules digital rules 170) associated with the identified recipient entity to use to determine which data is relevant from the one or more support content for generating the electronic registration.

At 312, the OSP 198 electronically extracts the identified data from the one or more support content in response to the electronically identifying the data. For example, this may include electronically extracting the identified data from one or more electronic documents.

At 314, the OSP 198 electronically verifies the extracted data.

At 316, the OSP 198 electronically generates the electronic registration based on the extracted data. In an example embodiment, the OSP 198 may use the entity identifier to identify which recipient entity and which digital rules (e.g., which of digital rules digital rules 170) associated with the identified recipient entity to use to generate the electronic registration. For example, this may include the registration engine 183 of the OSP 198 using a form generator to collate at least some the extracted data to electronically generate an electronic registration form according to digital rules (e.g., digital rules 170), which are based on requirements of a selected one of the one or more recipient entities to which the registration form will be sent. The electronic registration may also be based on existing data regarding the first entity already stored within a system that generates the electronic registration resulting from providing past electronic services calculating or remitting resources from the first entity to one or more recipient entities.

The OSP 198 may also present, via the GUI, a status of the electronic registration for each different recipient for which electronic registration is being performed for the first entity. For example, the status may be regarding, but is not limited to, one or more of: electronic signatures associated with the first entity needed from the first entity to complete registration and translations needed from the first entity to complete registration.

In an example embodiment, the OSP 198, based on the entity identifier, may electronically determine whether to electronically present a query via the GUI for additional data to electronically collect information regarding the first entity to facilitate automated preparation of the electronic registration. For example, this may be based on whether the additional data may be obtained using the entity identifier alone. The OSP 198 may then automatically modify the GUI in response to the determination whether to electronically present the query via the GUI for the additional data and electronically present the query via the GUI for the for additional data. The OSP 198 may then receive the additional data in response to the query. Electronically generating the electronic registration may then also be based on this additional data. In an example embodiment, this additional data may include information to facilitate locating the additional data.

In an example embodiment, the OSP 198 electronically receives digital registration rules regarding the GUI (some or all of which may be received via the GUI). The OSP 198 may then automatically modify the GUI according to the received digital registration rules to collect additional data via the GUI. The electronic collection of one or more support content from the Internet regarding the first entity to facilitate automated preparation of the electronic registration document may then also be based on this additional data.

FIG. 3B is a flowchart for illustrating a sample method 320, useful in the method 300 of FIG. 3A, for electronically receiving and verifying supplemental data according to embodiments of the present disclosure.

At 322, the OSP 198, before electronically generating the electronic registration based on the extracted data, electronically determines, based on the extracted data, whether to electronically present a query via the GUI for supplemental data regarding the first entity to facilitate automated preparation of the electronic registration. In some embodiments, the electronically generating the electronic registration is based on the extracted data and the supplemental data. In various example embodiments, the supplemental data may include, but is not limited to, one or more of: registration information regarding the first entity; information regarding the first entity stored by the at least one authority entity; information regarding the first entity available from public records identified using the entity identifier; information regarding the relationship instances between the first entity and a plurality of secondary entities; identification information regarding the first entity; location of the first entity; address of the first entity; name of an individual associated with the first entity; products provided by the first entity; services provided by the first entity; etc.

At 324 the OSP 198 automatically modifies the GUI in response to the determination whether to electronically present a query via the GUI for the supplemental data. For example, a questionnaire may be presented via the GUI for preparing the registration that has fewer questions and/or fewer request for actions than would have otherwise been presented if particular supplemental data regarding the registration had not been passed to the registration engine 183.

At 326 the OSP 198 electronically presents the query via the GUI for the supplemental data.

At 328 the OSP 198 electronically receives the supplemental data via the GUI in response to electronically presenting the query via the GUI for the supplemental data.

At 330 the OSP 198 electronically verifies the supplemental data.

FIG. 4 is a block diagram showing additional components of sample computer systems according to embodiments of the present disclosure. FIG. 4 shows details for a sample computer system 495 and for a sample computer system 490. The computer system 495 may be a server, while the computer system 490 may be a personal device, such as a personal computer, a desktop computer, a personal computing device such as a laptop computer, a tablet computer, a mobile phone, and so on. Either type may be used for the computer system 195 and 190 of FIG. 1 , a computer system that is part of OPF 189 and/or a computer system that is part of any entity or system shown in any of the Figures of the present disclosure.

The computer system 495 and the computer system 490 have similarities, which FIG. 4 exploits for purposes of economy in this document. It will be understood, however, that a component in the computer system 495 may be implemented differently than the same component in the computer system 490. For instance, a memory in a server may be larger than a memory in a personal computer, and so on. Similarly, custom application programs 474 that implement embodiments may be different, and so on.

The computer system 495 includes one or more processors 494. The processor(s) 494 are one or more physical circuits that manipulate physical quantities representing data values. The manipulation can be according to control signals, which can be known as commands, op codes, machine code, etc. The manipulation can produce corresponding output signals that are applied to operate a machine. As such, one or more processors 494 may, for example, include a Central Processing Unit (CPU), a Reduced Instruction Set Computing (RISC) processor, a Complex Instruction Set Computing (CISC) processor, a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), a Field-Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), any combination of these, and so on. A processor may further be a multi-core processor having two or more independent processors that execute instructions. Such independent processors are sometimes called “cores”.

A hardware component such as a processor may also include programmable logic or circuitry that is temporarily configured by software to perform certain operations. For example, a hardware component may include software executed by a general-purpose processor or another type of programmable processor. Once configured by such software, hardware components become specific specialized machines, or specific specialized components of a machine, uniquely tailored to perform the configured functions and are no longer general-purpose processors. It will be appreciated that the decision to implement a hardware component mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

As used herein, a “component” may refer to a device, physical entity or logic having boundaries defined by function or subroutine calls, branch points, Application Programming Interfaces (APIs), or other technologies that provide for the partitioning or modularization of particular processing or control functions. Components may be combined via their interfaces with other components to carry out a machine process. A component may be a packaged functional hardware unit designed for use with other components and a part of a program that usually performs a particular function of related functions. Components may constitute either software components (e.g., code embodied on a machine-readable medium) or hardware components. The hardware components depicted in the computer system 495, or the computer system 490, are not intended to be exhaustive. Rather, they are representative, for highlighting components that can be used with embodiments.

The computer system 495 also includes a system bus 412 that is coupled to the processor(s) 494. The system bus 412 can be used by the processor(s) 494 to control and/or communicate with other components of the computer system 495.

The computer system 495 additionally includes a network interface 419 that is coupled to system bus 412. Network interface 419 can be used to access a communications network, such as the network 188. Network interface 419 can be implemented by a hardware network interface, such as a Network Interface Card (NIC), wireless communication components, cellular communication components, Near Field Communication (NFC) components, Bluetooth® components such as Bluetooth® Low Energy, Wi-Fi® components, etc. Of course, such a hardware network interface may have its own software, and so on.

The computer system 495 also includes various memory components. These memory components include memory components shown separately in the computer system 495, plus cache memory within the processor(s) 494. Accordingly, these memory components are examples of non-transitory machine-readable media. The memory components shown separately in the computer system 495 are variously coupled, directly or indirectly, with the processor(s) 494. The coupling in this example is via the system bus 412.

Instructions for performing any of the methods or functions described in this document may be stored, completely or partially, within the memory components of the computer system 495, etc. Therefore, one or more of these non-transitory computer-readable media can be configured to store instructions which, when executed by one or more processors 494 of a host computer system such as the computer system 495 or the computer system 490, can cause the host computer system to perform operations according to embodiments. The instructions may be implemented by computer program code for carrying out operations for aspects of this disclosure. The computer program code may be written in any combination of one or more programming languages, including an object-oriented programming language such as Java, Python, Smalltalk or the like, and/or conventional procedural programming languages, such as the “C” programming language or similar programming languages such as C++, C Sharp, etc.

The memory components of the computer system 495 include a non-volatile hard drive 433. The computer system 495 further includes a hard drive interface 432 that is coupled to the hard drive 433 and to the system bus 412.

The memory components of the computer system 495 include a system memory 438. The system memory 438 includes volatile memory including, but not limited to, cache memory, registers and buffers. In embodiments, data from the hard drive 433 populates registers of the volatile memory of the system memory 438.

In some embodiments, the system memory 438 has a software architecture that uses a stack of layers, with each layer providing a particular functionality. In this example the layers include, starting from the bottom, an Operating System (OS) 450, libraries 460, frameworks/middleware 468 and application programs 470, which are also known as applications 470. Other software architectures may include less, more or different layers. For example, a presentation layer may also be included. For another example, some mobile or special purpose operating systems may not provide a frameworks/middleware 468.

The OS 450 may manage hardware resources and provide common services. The libraries 460 provide a common infrastructure that is used by the applications 470 and/or other components and/or layers. The libraries 460 provide functionality that allows other software components to perform tasks more easily than if they interfaced directly with the specific underlying functionality of the OS 450. The libraries 460 may include system libraries 461, such as a C standard library. The system libraries 461 may provide functions such as memory allocation functions, string manipulation functions, mathematical functions, and the like. In some embodiments, the computer program code may also be written, and software deployed, using a microservice architecture, which structures an application as a collection of services and/or containerization that that bundles an application's code with all the files and libraries it needs to run on any infrastructure. For example, the Kubernetes® open source tool may be used to automate the deployment, scaling, and management of containers without launching virtual machines for any applications.

In addition, the libraries 460 may include API libraries 462 and other libraries 463. The API libraries 462 may include media libraries, such as libraries to support presentation and manipulation of various media formats such as MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG. The API libraries 462 may also include graphics libraries, for instance an OpenGL framework that may be used to render 2D and 3D in a graphic content on the screen 491. The API libraries 462 may further include database libraries, for instance SQLite, which may support various relational database functions. The API libraries 462 may additionally include web libraries, for instance WebKit, which may support web browsing functionality, and also libraries for applications 470.

The frameworks/middleware 468 may provide a higher-level common infrastructure that may be used by the applications 470 and/or other software components/modules. For example, the frameworks/middleware 468 may provide various Graphic User Interface (GUI) functions, high-level resource management, high-level location services, and so forth. The frameworks/middleware 468 may provide a broad spectrum of other APIs that may be used by the applications 470 and/or other software components/modules, some of which may be specific to the OS 450 or to a platform.

The application programs 470 are also known more simply as applications and apps. One such app is a browser 471, which is a software that can permit the user 192 to access other devices in the internet, for example while using a Graphic User Interface (GUI). The browser 471 includes program modules and instructions that enable the computer system 495 to exchange network messages with a network, for example using Hypertext Transfer Protocol (HTTP) messaging.

The application programs 470 may include one or more custom applications 474, made according to embodiments. These can be made so as to cause their host computer to perform operations according to embodiments disclosed herein. Of course, when implemented by software, operations according to embodiments disclosed herein may be implemented much faster than may be implemented by a human mind if they can be implemented in the human mind at all; for example, tens or hundreds of such operations may be performed per second according to embodiments, which is much faster than a human mind can do. Such speed of operations, and thus the use of such computing systems and networks, are integral to the embodiments described herein because such operations would be practically useless unless they are able to be applied to hundreds or thousands of computer network clients simultaneously or concurrently across computer networks and to the vast volumes of data that change in real-time provided by such computer network clients. Implementing a practical application of the embodiments described herein to hundreds or thousands of computer network clients simultaneously or concurrently across computer networks on which they operate and to the vast volumes of data that change in real-time provided by such computer network clients is impossible to do in the human mind.

Other such applications 470 may include a contacts application, a social media application, an ERP application, a word processing application, a location application, a media application, a messaging application, and so on. Applications 470 may be developed using the ANDROID™ or IOS™ Software Development Kit (SDK) by an entity other than the vendor of the particular platform, and may be mobile software running on a mobile operating system such as IOS™, ANDROID™, WINDOWS® Phone, or other mobile operating systems. The applications 470 may use built-in functions of the OS 450, of the libraries 460, and of the frameworks/middleware 468 to create user interfaces for the user 192 to interact with.

The computer system 495 moreover includes a bus bridge 420 coupled to the system bus 412. The computer system 495 furthermore includes an input/output (I/O) bus 421 coupled to the bus bridge 420. The computer system 495 also includes an I/O interface 422 coupled to the I/O bus 421.

For being accessed, the computer system 495 also includes one or more Universal Serial Bus (USB) ports 429. These can be coupled to the I/O interface 422. The computer system 495 further includes a media tray 426, which may include storage devices such as CD-ROM drives, multi-media interfaces, and so on.

The computer system 490 may include many components similar to those of the computer system 495, as seen in FIG. 4 . In addition, a number of the application programs may be more suitable for the computer system 490 than for the computer system 495.

The computer system 490 further includes peripheral input/output (I/O) devices for being accessed by a user more routinely. As such, the computer system 490 includes a screen 491 and a video adapter 428 to drive and/or support the screen 491. The video adapter 428 is coupled to the system bus 412.

The computer system 490 also includes a keyboard 423, a mouse 424, and a printer 425. In this example, the keyboard 423, the mouse 424, and the printer 425 are directly coupled to the I/O interface 422. Sometimes this coupling is wireless or may be via the USB ports 429.

In this context, “machine-readable medium” or “computer-readable storage medium” refers to a component, device or other tangible media able to store instructions and data temporarily or permanently and may include, but is not be limited to: a thumb drive, a hard disk, random-access memory (RAM), read-only memory (ROM), buffer memory, flash memory, optical media, magnetic media, cache memory, an Erasable Programmable Read-Only Memory (EPROM), an optical fiber, a portable digital versatile disc (DVD), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. The machine that would read such a medium includes one or more processors 494.

The term “machine-readable medium” or “computer-readable storage medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) able to store instructions that a machine such as a processor can store, erase, or read. The term “machine-readable medium” shall also be taken to include any medium, or combination of multiple media, that is capable of storing instructions (e.g., code) for execution by a machine, such that the instructions, when executed by one or more processors of the machine, cause the machine to perform any one or more of the methods described herein. Accordingly, instructions transform a general or otherwise generic, non-programmed machine into a specialized particular machine programmed to carry out the described and illustrated functions in the manner described.

A computer readable signal traveling from, to, and via these components may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Operational Examples—Use Cases

The above-mentioned embodiments have one or more uses. Aspects presented below may be implemented as was described above for similar aspects. (Some, but not all, of these aspects have even similar reference numerals.)

Use cases for the technological solutions disclosed herein can be in, but are not limited to, the fields of compliance, for example, tax or other business compliance with a government authority or any set of requirements. However, the possible use of such technological solutions disclosed herein in various practical fields does not make such solutions non-technical in nature or abstract ideas.

Businesses are required by law to determine the amounts of money they owe as taxes to various tax jurisdictions, and then pay these amounts to the tax jurisdictions. Each time, there may be more than one tax jurisdiction that money is owed to. If they fail to accurately report and pay taxes they owe, they may be subject to audits and fines. Not knowing is not an excuse. When businesses make, sell, or buy goods, more taxes may come due. Such taxes include sales taxes, excise taxes, use taxes, value-added taxes, and so on, to multiple jurisdictions. Makers of goods may be subject to excise taxes, and excise taxes may thus impact the supply chain.

Determining the taxes due is very complex. There are over 11,000 tax jurisdictions in the US, and many more worldwide, and almost 10 million taxability rules related to products and services. Sellers of goods are subjected to many requirements about the taxes they owe. In particular, they must determine whether, and when, they must collect taxes in each tax jurisdiction, such as each state, locality, etc. For each state, a seller may need to register with that state's taxing agency, set up internal processes for collecting sales tax in accordance with the tax rules of the state, keeping records for the collected sales tax, file reports and tax returns with the state, and finally pay the tax to the state.

Sellers are also subject to requirements for instances when they do not owe sales tax. For instance, while each tax jurisdiction taxes many products and services, it does not tax all of them. In some instances, the products being sold may be exempt from taxes, but that requires detailed research. For instance, while deodorant was taxable in 2018 in Texas, anti-perspirant was tax exempt. At the same time, cowboy boots were exempt from sales tax in Texas, but not in New York. Plus, when a seller buys certain items for resale, the items may be exempt from sales tax as long as the seller creates and maintains proper certificates.

For selling taxable items, each jurisdiction has its own tax rules. Sellers are faced with challenging complexities about these tax rules. Complexities in determining the sales tax due may arise from the location of the buyer and the seller, or a distributor, etc. For instance, some state and local tax authorities have origin-based rules, which means that a sales tax is charged from the seller's location, while other state and local tax authorities have destination-based rules, which means that a sales tax is charged from the buyer's location. Additional complexities arise from the fact that different tax jurisdictions charge different percentage rates. And these different tax jurisdictions can be different states, or a) a state, plus different cities within the state, and so on. In each instance the select must collect, report, and pay the correct amount for each locality.

Businesses generally collect information relating to their operations, such as by using technologies including enterprise resource planning (“ERP”) applications and accounting applications. ERP technology manages information relating to a business's activities, such as sales, resource management, production, inventory management, delivery, billing, and so on. Accounting applications manage a business's accounting information, such as purchase orders, sales invoices, payroll, accounts payable, accounts receivable, and so on.

ERP applications, accounting applications, and other conventionally used technology generally cannot provide accurate tax information and efficient registrations in various jurisdictions, such as when transactions are complex or span geographical boundaries. As an example, these applications may over-estimate or under-estimate tax owed to governments, for example by failing to consider municipal taxes. Moreover, such applications generally do not provide an ability for businesses to model the impact various changes may have on the business's bottom line. As an example, these applications cannot model the impact on taxes of transferring production of goods from one geographical area (e.g., tax jurisdiction) to another.

Businesses have tax obligations to various tax authorities of respective tax jurisdictions. A first challenge is in making the related determinations. Tax-related determinations, made for the ultimate purpose of tax compliance, are challenging because the underlying statutes and tax rules and guidance issued by the tax authorities are very complex. There are various types of tax, such as sales tax, use tax, excise tax, VAT, lodging tax, and many more. Some types of tax are industry specific. Some are specific to particular jurisdictions (e.g., VAT does not currently exist in the U.S.). Each type of tax has its own set of rules. Additionally, statutes, tax rules, and rates change often, and new tax rules are continuously added. Compliance becomes further complicated when a taxing authority offers a temporary tax holiday, during which certain taxes are waived.

Tax jurisdictions are defined mainly by geography. Businesses have tax obligations to various tax authorities within the respective tax jurisdictions. There are various tax authorities 580, such as that of a country, of a state, of a municipality, of a local district such as a local transit district and so on. So, for example, when a business sells items in transactions that can be taxed by a tax authority, the business may have the tax obligations to the tax authority. These obligations include requiring the business to: a) register itself with the tax authority's taxing agency, b) set up internal processes for collecting sales tax in accordance with the sales tax rules of the tax authority, c) maintain records of the sales transactions and of the collected sales tax in the event of a subsequent audit by the taxing agency, d) periodically prepare a form (“tax return”) that includes an accurate determination of the amount of the money owed to the tax authority as sales tax because of the sales transactions, e) file the tax return with the tax authority by a deadline determined by the tax authority, and f) pay (“remit”) that amount of money to the tax authority. In such cases, the filing and payment frequency and deadlines are determined by the tax authority.

A technical challenge for businesses is that the above-mentioned technology generally cannot provide tax information that is accurate enough for the businesses to register with the relevant tax authorities 580 and to be tax compliant with all the relevant tax authorities 580. The lack of accuracy may manifest itself as missing data for registration, errors in the amounts determined to be owed as taxes to the various tax authorities, and it is plain not good to have such missing data and errors. For example, businesses that sell products and services have risks whether they over-estimate or under-estimate the sales tax due from a sale transaction. On the one hand, if a seller over-estimates the sales tax due, then the seller collects more sales tax from the buyers than was due. Of course, the seller may not keep this surplus sales tax, but instead must pay it to the tax authorities—if they cannot refund it to the buyers. If a buyer later learns that they paid unnecessarily more sales tax than was due, the seller risks at least harm to their reputation. Sometimes the buyer will have the option to ask the state for a refund of the excess tax by sending an explanation and the receipt, but that is often not done as it is too cumbersome. On the other hand, if a seller under-estimates the sales tax due, then the seller collects less sales tax from the buyers, and therefore pays less sales tax to the authorities than was actually due. That is an underpayment of sales tax that will likely be discovered later, if the tax authority audits the seller. Then the seller will be required to pay the difference, plus fines and/or late fees, because ignorance of the law is not an excuse. Further, one should note that sales taxes are considered trust-fund taxes, meaning that the management of a company can be held personally liable for the unpaid sales tax.

For sales in particular, making correct tax registrations and determinations for sales (e.g., sales tax in the U.S. and VAT in other non-U.S. jurisdictions) and use tax is even more difficult. There are a number of factors that contribute to its complexity.

First, some tax authorities have origin-based tax rules, while others have destination-based tax rules. Accordingly, a sales tax may be charged from the seller's location or from the buyer's location.

Second, the various tax authorities assess different, i.e., non-uniform, percentage rates of the sales price as sales tax, for the purchase and sale of items that involve their various tax jurisdictions. These tax jurisdictions include various countries, local regions, cities, municipalities, special taxing jurisdictions, and so on. In fact, there are over 10,000 different tax jurisdictions in the US alone, with many partially overlapping.

Third, in some instances no sales tax is due at all because of the type of item sold. For example, in 2018 selling cowboy boots was exempt from sales tax in Texas, but not in New York. This non-uniformity gives rise to numerous individual rules for tax registration and taxability rules related to various products and services across different tax jurisdictions.

Fourth, in some instances no sales tax is due at all because of who the individual buyer is. For example, certain entities are exempt from paying sales tax on their purchases, so long as they properly create and sign an exemption certificate and give it to the seller for each purchase made. Entities that are entitled to such exemptions may include wholesalers, resellers, non-profit charities, educational institutions, etc. Of course, who can be exempt is not exactly the same in each tax jurisdiction. And, even when an entity is entitled to be exempt, different tax jurisdictions may have different requirements for the certificate of exemption to be issued and/or remain valid.

Fifth, it can be difficult to determine which tax authorities a seller owes sales tax to. A seller may start with tax jurisdictions that it has a physical presence in, such as a main office, a distribution center or warehouse, an employee working remotely, and so on. Such ties with a tax jurisdiction establish the so-called physical nexus. However, a tax authority such as a, country, state/region, or even a city may set its own nexus rules for when a business is considered to be “engaged in business” with it, and therefore that business is subject to registration and collection of taxes based on the transaction. For example, in the U.S., these nexus rules may include different types of nexus, such as affiliate nexus, click-through nexus, cookie nexus, economic nexus with thresholds, and so on. For instance, due to economic nexus, a remote seller may owe sales tax for sales made in the jurisdiction that are a) above a set threshold volume, and/or b) above a set threshold number of sales transactions.

Even where a seller might not have reached any of the thresholds for economic nexus, a number of states are promulgating marketplace facilitator laws that sometimes use such thresholds. According to such laws, intermediaries that are characterized as marketplace facilitators per laws of the state have an obligation, instead of the seller, to collect sales tax on behalf of their sellers, and remit it to the state. The situation becomes even more complex when a seller sells directly to a state, and also via such an intermediary.

A value-added tax (“VAT”), also known as a goods and services tax (“GST”) in some countries, is broad consumption tax assessed on the value added to goods and services. VAT is an indirect type of tax or transactional tax that is assessed incrementally. It is levied on the price of a product or service at each stage of production, distribution, or sale to the end consumer. In other words, value-added tax is designed to tax only the value added by a business on top of the services and goods it can purchase from the market. VAT is an indirect tax because the person who ultimately pays the tax is not necessarily the same person as the one who remits the tax to the tax authorities.

VAT is usually implemented as a destination-based tax, where the tax rate is based on the location of the consumer and applied to the sales price, but many exemptions apply, which makes it a complex tax to calculate. For example, if the ultimate consumer is a business that collects and pays to the government VAT on its products or services, it may reclaim the tax paid. The amount of VAT is decided by the jurisdiction as a percentage of the price of the goods or services provided.

FIG. 5 is a diagram of an example adaptive registration system (ARS) 604 that provides a technical solution to many of the above technical problems, including sample aspects for describing operational examples and use cases of embodiments of the present disclosure that are improvements in automated computerized systems.

As an example of a use case, there is a need for managing and processing data associated with resources that obligates a person or entity to pay another entity, such as a government authority (e.g., a tax authority) for certain relationship instances or interchanges (e.g., transactions that occurred in a jurisdiction, marketplace, online, in a specific business sector, involving certain products or services, and so on). One such type of resource may be a tax, such as a value added taxation (VAT), sales tax, or other type of tax. In the example use case of VAT, the electronic calculation of the correct VAT and electronic preparation for filing VAT registration documents and VAT tax returns for thousands upon thousands of transactions for hundreds or thousands of sellers is complex and laborious. Such a seller may be a customer or client of an OSP (referred to herein as a customer/seller or client), such as OSP 598, and access the OSP 598 via client device 593 over network 188. Before an OSP customer/seller can file tax returns to meet tax compliance requirements for their activities, registration of the customer/seller is often required, upon which an identifier such as a customer number, registration number, or account number is issued. Once the customer number, for example, is issued, the customer/seller may then file tax returns with one or more corresponding tax authorities (e.g., tax authority 581, tax authority 582, . . . ) represented by the set of tax authorities 580.

The OSP 598 may be configured to provide an automated electronic service for processing and generating a registration document, represented by tax registration 579, to be submitted to, for example, a tax authority (e.g., tax authority 581) that requires it before being able to electronically file a tax return associated with resources, such as VAT taxes. Such processing and generating the tax registration may be performed by the registration engine 583 for hundreds or thousands of clients via hundreds or thousands of remote client devices 593 over network 188 simultaneously or concurrently (which is impossible to do in the human mind) to provide more accurate and efficient computer network operations for electronic document generation for various systems on the network, including the client devices and devices of the set of tax authorities 580, thus improving the technology of computer networks and the technology of electronic document generation.

In particular, Such processing and generating the tax registration performed by the registration engine 583 for hundreds or thousands of clients via hundreds or thousands of remote client devices 593 over network 188 simultaneously or concurrently increases the speed at which the electronic services are provided (as opposed to the devices waiting for them to be performed serially). This reduces data flows over the computer network by avoiding the client devices having to resend requests to perform the electronic services and provide updated data due to lag times that would otherwise be experienced by the client devices between when the original request was sent and when the electronic operations are actually able to be performed. Thus, the systems and methods described herein for automated actions for automated preparation and submission of electronic registration improve the functioning of computer or other hardware, such as by reducing the processing, storage, and/or data transmission resources needed to perform various tasks, including preparation and submission of electronic registration, thereby enabling the tasks to be performed by less capable, capacious, and/or expensive hardware devices, and/or be performed with less latency, and/or preserving more of the conserved resources for use in performing other tasks or additional instances of the same task.

Operational examples and sample use cases are possible where the attribute of an entity in a dataset, such as dataset 535, is any one of: the entity's name; type of entity; a physical location such as an address; a contact information element; transactions of the entity; a pre-existing entity identifier that had been previously used by an electronic system of at least one authority entity to identify the entity; an identifier of a specific source of revenue received for a transaction of the entity; characteristics of transactions of the entity; licensure and/or or registration of the entity and/or products or services the entity produces, sells, stores and/or transfers; business registrations of the entity; documents and/or images of the entity; governmental documents of the entity; government issued identification (ID) documents of the entity or a person associated with the entity; products or services produced, sold, stored and/or transferred by the entity; types of products or services produced, sold, stored and/or transferred by the entity; a location to which products are sent, shipped or transferred; a location from which products are received; a location of a property owned by the entity; a location of a property owned by the entity within a particular region of other domain; an affiliation; a characterization of another entity; a characterization by another entity; an association or relationship with another entity (general or specific instances); an asset of the entity; a declaration by or on behalf of the entity; and so on. Different resources may be produced in such instances, and so on.

FIG. 5 is a diagram for an operational example and use case where a tax registration 579 is electronically prepared for a client (i.e., customer) of the OSP 598 (e.g., a seller of goods and/or services) associated with client device 593 by the OSP 598 using tax registration engine 583. The tax registration 579 may enable the preparation and sending of an associated tax return document by the OSP 598 for the transactions of the seller with a secondary entity (e.g., a buyer). In an example embodiment, the tax registration engine 583 may electronically initiate a process to collect data via a graphical user interface (GUI) of the client device 593 (e.g., adaptive UI 540) over network 188 to facilitate automated preparation of an electronic tax registration 579. This process may be configured to occur before initiating a process by the OSP 598 to remit tax payments from the client to one or more recipient entities, such as one or more of the tax authorities 580, based on transactions between the client and a plurality of buyers or recipients of goods and/or services.

The identifier component 552 may create or associate a business identifier, customer number, account number, or other customer identifier, etc. The customer identifier can be used to search for customer information to enable the automated registration process. For example, the identifier component 552 may electronically obtain from client device 593 or another source, via network 188, a pre-existing entity identifier of the client that had been previously used by an electronic system of at least one of the tax authorities 580 to identify the client. The identifier component 552 may then electronically associate the pre-existing entity identifier with the client. The Docufetch component 554 may then, using at least the entity identifier, perform automated actions via network 188 to electronically collect support content from the Internet or other sources, via network 188, regarding the client to facilitate automated preparation of the tax registration 579.

As one example, such support content may be collected from public/government web sites 566. For example, the Docufetch component 554 may be configured to search for customer information, based on known information about the customer, whether provided by the customer manually or obtained by the activities of the ARS 604. In some embodiments, the Docufetch component 554 may employ web crawlers to go through government websites, searching for customer information, for example, by using a customer identifier. The user adaptive UI 540 and webcrawler of the Docufetch component 554 may, for example, work together to download documents and electronically pull documents into the OSP 598. The Docufetch component 554 may also use web application programming interfaces (APIs). In some embodiments, user input may indicate where the customer or associated entity or business is from or located. Based on this user input, the digital tax registration rules 570 may be electronically consulted to automatically choose which web site or data source site it has to interact with to obtain certain information for the tax registration process. In various embodiments, the digital tax registration rules 570 may be electronically consulted based upon modifiable workflow configurations.

A translator 568 may also be utilized by the tax registration engine 583 to translate documents and/or data related to the tax registration 579 to be in a language and/or format readable, compatible or otherwise acceptable by an applicable tax authority and/or the tax registration engine 583. The information extractor 556 may then electronically identify data from the support content relevant to the electronic registration and electronically extract the identified data from the support content in response to electronically identifying the data by the identifier component 552. For example, once documents have been fetched by the Docufetch component 554, which may be based on the user input and consulting the digital tax registration rules 570, the system uses appropriate technology, such as, for example optical character recognition (OCR), a portable document format (PDF) editor, etc., to extract information. Once information is extracted, the data may be returned or processed in a format that can be consumed by users for a particular purpose or used by the ARS 604 for the next process.

In an example embodiment, once a document is in the OSP 598 (e.g., saved as one or more documents 562 in memory 594), depending on the document, or format (which can be dictated by language, jurisdiction, purpose, technology (PDF format, MS Word format, particular image format, etc.) and so on), information is extracted from the document in accordance with the type of document and/or format. In some embodiments, existing technology may be used, such as OCR, or other available character or object recognition technology (e.g., OnFido), to scrape content from a document to pull necessary information and prepopulate a UI questionnaire, registration form, etc. In turn, the extracted content may be configured into a specific format for a specific purpose, the ARS 604 being able to place the content in any number of formats. The registration engine 583 may then electronically verify the extracted data and electronically generate and/or electronically file or otherwise submit the tax registration 579 based on the extracted data.

It will be recognized that aspects of FIG. 5 have similarities with aspects of FIG. 1 . Portions of such aspects may be implemented as described for analogous aspects of FIG. 1 . In particular, a thick line 515 separates FIG. 5 , although not completely or rigorously, into a top portion and a bottom portion. Above the line 515 the emphasis is mostly on entities, components, their relationships, and their interactions, while below it the emphasis is mostly processing of data that takes place often within one or more of the components above the line 515.

Above the line 515, a computer system 595 is shown, which is used to help customers, such as a client associated with client device 593, with tax compliance. Further in this example, the computer system 595 is part of an OSP 598 that is implemented as a Software-as-a-Service (SaaS) provider, for being accessed by the client online. Alternately, the functionality of the computer system 595 may be provided locally to a user.

In embodiments, the client device 593 can be a device of a business, such as a seller of items, a reseller, a buyer, and so on. In this present case, the client device 593 is a device of an individual or business that sells goods or services. In such instances, the user of the client device 593 can be an employee, a contractor, or otherwise an agent of the business. In such cases the client device 593 can even be that of an online seller, but that is not necessary.

In a number of instances, the user of the client device 593 uses software applications and ERP technology to manage business activities, such as sales, resource management, production, inventory management, delivery, billing, and so on. Such software applications, and more, may be used locally by the user of the client device 593, or from an Online Processing Facility (OPF) 589 that has been engaged for this purpose by the user of the client device 593, and/or the client device 593. In such use cases, the OPF 589 can be a Mobile Payments system, a Point Of Sale (POS) system, an accounting application, an Enterprise Resource Planning (ERP) system or provider, an e-commerce provider, an electronic marketplace, a Customer Relationship Management (CRM) system, and so on.

To help with such complex determinations and solve such technical problems, the computer system 595 may be specialized device for tax compliance as disclosed herein. The computer system 595 may have one or more processors and memory 594, for example, as was described for the computer system 195 of FIG. 1 . The computer system 595 thus implements tax registration engine 583 to electronically generate the electronic tax registration 579 based on application of the digital tax registration rules 570 to the extracted data. Other components of the OSP 598 may make the determinations of tax obligations and perform electronic preparation and sending of associated tax return document(s) to applicable tax authorities 580. The registration engine 583 can as described as an example instance of the registration engine 183 of FIG. 1 .

The computer system 595 may further store locally entity data, i.e., data of an entity associated with client device 593, any of which/whom may be a customer of OSP 598 and/or a seller or a buyer in a sales transaction in various embodiments. The entity data may include profile data of the customer and transaction data (e.g., including a pre-existing entity identifier that had been previously used by an electronic system of at least one authority entity to identify the entity and/or support content) based on which a tax registration 579 may be performed and a determination of a tax obligation is desired. In the online implementation of FIG. 5 , the OSP 598 has (or has access to) a memory 594 for storing the entity data and registration rules 564, which may comprise, include or be part of the digital tax registration rules 570. This entity data may be inputted by the user of the client device 593, caused to be downloaded or uploaded by the user of the client device 593 or from the OPF 589, extracted from the documents/images 548 stored in memory 546, extracted from the documents/images 562 stored in memory 594, and/or obtained from the OPF 589, and so on. In other implementations, a simpler memory configuration may suffice for storing the entity data. In various embodiments the documents/images 548 and/or documents 562 may include, but are not limited to: licensure and/or or registration documents of the entity and/or products or services the entity produces, sells, stores and/or transfers; Trade Registrations; business registrations of the entity; documents and/or images of the entity; tax registrations of the entity; governmental documents of the entity; government issued identification (ID) documents of the entity, etc.

Registration rules 564 are further implemented within the OSP 598. The registration rules 564 can be a utility that stores digital tax registration rules 570 for use by the registration engine 583. As part of managing registration rules 564, there may be continuous updates of the digital tax registration rules 570, by inputs gleaned from a set 580 of different tax authorities 581, 582, . . . . Updating may be performed by humans, or automatically by computers, and so on. As mentioned above, the number of the different tax authorities in the set 580 may be very large.

For a specific tax registration 579 and determination of a tax obligation, the computer system 595 may receive one or more datasets. A sample received dataset 535 is shown just below line 515, which can be similar to what was described for the dataset 135 of FIG. 1 . In this example, the computer system 595 transmits a request 584 that includes a payload 534, and the dataset 535 is received by the computer system 595 parsing the received payload 534. In this example, the single payload 534 encodes the entire dataset 535, but that is not required, as mentioned earlier.

In this example, the dataset 535 has been received because it is desired to perform a tax registration 579 for an entity associated with the client device 593. As such, the sample received dataset 535 has values that characterize attributes of the client (e.g., a seller) and possibly also buy-sell transactions, as indicated by an arrow 599. (It should be noted that the arrow 599 describes a correspondence, but not the journey of the data of the client and buy-sell transaction in becoming the received dataset 535.) Accordingly, in this example the sample received dataset 535 has a value ID for an identity of the dataset 535 and/or the transaction. The dataset 535 may also have a value PE for a pre-existing entity identifier that had been previously used by an electronic system of at least one authority entity to identify the client and perhaps also the name of the client device 593 or the user, which can be the seller making sales transactions, some online. The dataset 535 further has a value PD for relevant data of the client device 593 or the user, such as an address, place(s) of business, prior nexus determinations with various tax jurisdictions, and so on. The dataset 535 may also have a value SE for the name of a secondary entity, which can be the buyer and/or a recipient of goods or services. The dataset 535 may further have a value SD for relevant data of the secondary entity (the buyer and/or a recipient of goods or services), such as relevant, identification information entity-driven exemption status, and so on. The dataset 535 may have a value B2 for the sale price and/or value of the item or items sold, shipped and/or received.

The dataset 535 may further have a value RS that includes a unique identifier that contains or identifies information identifying or regarding a revenue source system for revenue received for the transaction. The dataset 535 may have fewer values or have additional values, as indicated by the dot-dot-dot in the dataset 535. These values may characterize further attributes, such as characteristics of goods or services sold, data identifying of or otherwise relating to a license or registration required for the transaction, a date and possibly also time of the transaction, and so on.

The digital tax registrations rules 570 have been created so as to accommodate tax rules that the set 580 of different tax authorities 581, 582 . . . promulgate within the boundaries of their tax jurisdictions and workflow configurations and settings. In FIG. 5 , five sample digital tax rules are shown, namely T_RULE2 572, T_RULE3 573, T_RULE5 575, T_RULE6 576 and T_RULE7 577. Additional digital tax registrations rules 570 are suggested by the vertical dot-dot-dots. Similarly with FIG. 1 , some of these digital tax rules may be digital main rules that determine the tax registration 579, while others can be digital precedence rules that determine which of the digital main rules is to be applied in the event of conflict. In some use cases, digital main rules may be about a sales tax, VAT tax or use tax being owed due to the transactions of an entity associated with client device 593 at a certain percentage of a purchase price or determined value (or value added). Digital precedence rules may be digital tax rules that determine whether particular digital tax rules are to be applied for origin-based or destination-based jurisdictions, how to override for diverse taxability of individual items, for temporary tax holidays, for exemptions from having to pay tax based on who the buyer is, and also based on nexus, and so on. In the present example, digital precedence rules may be digital tax rules that determine whether particular digital tax rules (including specific tax registration rules) are to be applied based on one or more tax jurisdictions in which a particular entity, goods delivery or transaction is located, and/or where the client is in the process of preparing and submitting a tax registration.

Similarly with FIG. 1 , these digital tax registration rules 570 can be implemented or organized in different ways. In some use cases they can be organized with conditions and consequents, such as was described earlier in this document. Such conditions may relate to geographical boundaries, sources of revenue, effective dates, location of goods deliver or shipment, estimated or determined value of goods, where the client is in the process of preparing and submitting a tax registration, and so on, for determining where, when and how a tax registration is to be performed, and when or where a digital tax rule or tax rate is to be applied. These conditions may be expressed as logical conditions with ranges, dates, other data, and so on, and may be dictated by, or otherwise based on, workflow configurations and settings. Values of the dataset 535 can be iteratively tested against these logical conditions according to arrows 571. In such cases, the consequents may indicate one or more tax obligations, such as to indicate different types of tax registrations that are required, taxes that are due, rules, rates, exemption requirements, reporting requirements, remittance requirements, etc.

In this example, a certain digital tax rule T_RULE6 575 is shown as identified and used, which is indicated also by the beginning of an arrow 578. Identifying may be performed responsive to the values of the dataset 535, which are shown as considered for digital tax registration rules 570 by arrows 571. For example, it can be recognized that a condition of the digital tax registration rule T_RULE6 575 is met by one or more of the values of the dataset 535. For instance, it can be further determined that automated actions to electronically collect one or more support content from the Internet or other sources regarding an entity associated with client device 593 are to be performed to facilitate automated preparation of the electronic registration document for the entity.

As such, the computer system 595 may perform the tax registration 579 with one or more of the applicable tax authorities in the set of tax authorities 580 via network 188, which is akin to performing the registration 179 of FIG. 1 . The computer system 595 may also file or otherwise send (or cause to be filed or sent) a corresponding tax return document to one or more of the applicable tax authorities in the set of tax authorities 580 via network 188. The tax registration 579 can be produced by the computer system 595 applying the certain digital tax registration rule T_RULE6 575, as indicated by the arrow 578. In this example, the consequent of the identified certain digital tax rule T_RULE6 575 may specify to extract the data identified from support content in response to electronically identifying the data in the support content (e.g., relevant data identified in a collected electronic document), electronically perform the tax registration 579 based thereon, and so on.

The computer system 595 may then cause a notification 536 to be transmitted. The notification 536 can be about an aspect of the tax registration 579, similar to the notification 136 of FIG. 1 . In the example of FIG. 5 , the notification 536 is caused to be transmitted by the computer system 595 as an answer to the received dataset 535. The notification 536 can be about an aspect of the tax registration 579. In particular, the notification 536 may inform about the aspect of the tax registration 579, namely its status, that it has been generated, determined, filed and/or transmitted, where it can be found, what it is, or at least a portion or a statistic of its content, and so on.

The notification 536 can be transmitted to one of an output device and another device that can be the remote device, from which the dataset 535 was received. The output device may be the screen of a local user or a remote user (e.g., a screen of client device 593). The notification 536 may thus cause a desired image to appear on the screen, such as within a Graphical User Interface (GUI) and so on. The other device may be a remote device, as in this example. In particular, the computer system 595 causes the notification 536 to be communicated by being encoded as a payload 537, which is carried by a response 587. The response 587 may be transmitted via the network 188 responsive to the received request 584. The response 587 may be transmitted to the client device 593, to OPF 589, and so on. As such, the other device can be the client device 593, or a device of the OPF 589, or a screen of such devices. In this example the single payload 537 encodes the entire notification 536, but that is not required, similarly with what is written above about encoding datasets in payloads. Along with the aspect of the tax registration 579, it is advantageous to embed in the payload 537 the ID value and/or one or more values of the dataset 535. This will help the recipient correlate the response 587 to the request 584, and therefore match the received aspect of the tax registration 579 as the answer to the received dataset 535.

In an example embodiment, the client device 593, may have a certain application (not shown) which may, for example, be developed using a Software Development Kit (SDK) 542 and may have a connector 544 that is a plugin that sits on top of that certain application. The connector 544 may be able to send and/or receive the details required for the service desired from the OSP 598, form an object or payload 534, and then send or push a request 584 that carries the payload 534 to the tax registration engine 583 via a service call. The tax registration engine 583 may receive the request 584 with the payload 534. The tax registration engine 583 may then apply digital tax registration rules 570 to the payload 534 to obtain, collect, extract, identify, associate and/or verify data; generate an electronic tax registration form or document; perform an electronic tax registration 579, determine a requested resource and/or form a payload 537 that is an aspect of such operations, the electronic tax registration 579 and/or the resource. The tax registration engine 583 may then push, send, or otherwise cause to be transmitted a response 587 that carries the payload 537 to the connector 544. The connector 544 reads the response 587, and forwards the payload 537 to the certain application of the client device 593. The same or similar process may be performed by the tax registration engine 583 for electronically submitting the tax registration 579 to respective systems of the tax authorities 580.

An adaptive user interface (UI) 540 to the OSP 598 for processing registrations for registering with one or more of the tax authorities 580 or for filing a tax return may be presented on the client device 593. In an example embodiment, before electronically generating the tax registration 579 based on the extracted data, the tax registration engine 583 electronically determines, based on the extracted data, whether to electronically present a query via the adaptive UI 540 for supplemental data regarding the entity associated with the client device 593 in order to facilitate automated preparation of the electronic tax registration 583. The tax registration engine 583 may automatically modify the adaptive UI 540 in response to the determination whether to electronically present a query via the adaptive UI 540 for the supplemental data. The tax registration engine 583 may electronically present the query via the adaptive UI 540 for the supplemental data. The tax registration engine 583 may then electronically receive the supplemental data over network 188 via the adaptive UI 540 in response to electronically presenting the query via the adaptive UI 540 for the supplemental data and electronically verify the supplemental data. The OSP 598 may also have an OSP internal adaptive UI 569 that automatically changes or is modified for administrators of the OSP 598.

Referring now also to FIG. 6 , shown is a block diagram illustrating an example Workflow-as-a-Service (WFaaS) component 602 of the OSP 598 for registering with a tax authority or for filing a tax return that is an improvement in automated computerized systems, according to various embodiments of the present disclosure. In various embodiments, the WFaaS component 602 may comprise, be implemented by, be communicatively coupled to, or be part of the OSP 598. One example configuration of WFaaS component 602 is demonstrated by Workflow as a Service 550 of FIG. 5 in the OSP 598.

The WFaaS component 602 manages and controls such systems of the OSP 598 for efficient and accurate operations, for organizing vast amounts of information concurrently and/or simultaneously, to process documents, and to set up and manage workflow processes. The WFaaS component 602 is also configured to concurrently and/or simultaneously manage and process data/information for a large number of clients for the purposes of preparing documents associated with registration for filing, for example, a VAT return, and any other processes related to the registration and return filing. The overall system of FIG. 6 is configured to require a minimal amount of customer (i.e., client) involvement and automate the tax registrations and processing and filing of these returns. The customers of this system set the parameters up front, and then are able to forget about the remaining process, providing an automated, worry-free registration service.

The OSP 598 and associated WFaaS component 602 (e.g., WFaaS 550 shown in FIG. 5 ) enable, via a scalable resource return filing system component 606, a scalable workflow platform and infrastructure to provide services such as tax registration, preparing tax documents, and filing such documents in an automated manner. The scalable resource return filing system component 606 may comprise, include, be implemented by and/or be part of the tax registration engine 583 of the OSP 598. In an example embodiment, the scalable resource return filing system component 606 is in operable communication with the WFaaS component 602. The use cases involving these services include providing direct and indirect tax compliance solutions with a tax authority, such as electronic VAT registration, electronic VAT returns, automatic filings, reconciliation reports and generating client reports. In some embodiments, the WFaaS component 602 functions as a technological toolbox to power the generation of registrations and returns, and the data associated with these processes, to facilitate the entire registration process and/or tax return filing process in an automated manner, as an example of a use case.

The WFaaS component 602 of the OSP 598 is configured to create workflows and implement how to mitigate failure events. In some embodiments, the WFaaS component 602 is configured to create, control, manage and enable the workflows. In some embodiments, the WFaaS component 602 enables the generation and management of documents and forms, such as a registration form based on one or more combinations of received client data, business related data, history of client data and activities within the OSP 598, to automate the process for generating registration forms and filing them with the proper external entity.

In some embodiments, machine learning techniques are utilized and improve upon the accuracy and speed at which registration documents, and other related documents are collected and processed. In various embodiments, the ARS 604 may comprise, include, be implemented by or be part of the tax registration engine 583, the OSP 598, the client device 593 and/or any other device, component or system depicted in FIG. 5 . In an example embodiment, the ARS 604 is in operable communication with the WFaaS component 602 and includes a set of tools developed to simplify the registration process for creating tax related compliance documents to submit to an external government entity, such as a tax authority, in an automated and/or hands-free way where the customer sets it and forgets it.

Although not all the components of a computer system are shown in FIG. 5 and FIG. 6 for purposes of illustrating the ARS 604, it will be understood that other components of a computer system are present. Referring again to FIG. 5 , in an example embodiment, on the client device 593, the adaptive UI 540 is configured such that data can be manually entered or the system can be configured to automatically send or receive data to display on the interface of the client device 593. In some embodiments, a user of the ARS 604 may manually enter, upload, send, view or receive data via the adaptive UI 540. In some embodiments, the adaptive UI 540 may update content for the user while the system is in the process of generating a registration form. Also, in some embodiments, the updating of content occurs in real time and/or simultaneously or concurrently while updating corresponding data for other clients.

In some instances, in addition to typical data, signals and protocols, the request data (e.g., in request 584) may include the actual/original document, business identifier, etc., sent from the client device 593, and response data (e.g., in response 587) may include the parsed/extracted data from the documents (after the extraction by the ARS 604).

The OSP 598 also includes a memory 594 for storing documents and other data, which may include data provided by a user at the client device 593 and data extracted and/or processed by the ARS 604. The memory 594 also includes a set of registration rules 564 that the WFaaS component 602 or tax registration engine 583 may confer to make necessary decisions to update the adaptive UI 540 in real time or generate an accurate registration form, as an example.

The WFaaS component 602 may be configurable by administrators or other agents of the ARS 604 and control the workflows of the ARS 604 to manage the data collected, generated, and processed, and the process for generating a registration form. In embodiments, the WFaaS component 602, which may comprise or be part of the tax registration engine 583, may include or control the identifier component 552 to create or associate a business identifier, customer number, account number, etc. The customer identifier can be used to search for customer information. The WFaaS component 602 may also include or control the Docufetch component 554 that is configured to go through government websites and other sites containing public records, and to search for and gather customer information using, for example, a user interface and webcrawler. Documents may be downloaded into the OSP 598 to process via information extractor 556. Information extractor 556 extracts data being searched about the customer and/or business/activities from documents downloaded from the Internet or other sources. The WFaaS component 602 may also include or control the form generator 558 which collates the customer information necessary to generate a form, and is also configured to automatically file the form with, for example, one or more of the tax authorities 580.

FIG. 7 is a flowchart for illustrating a sample method 700 for electronically generating a registration form for registering with a value added taxation (VAT) tax authority or for filing a VAT tax return according to an embodiment of the present disclosure.

At 702, the ARS 604 receives user input and defines that user input as a customer identifier or creates a customer identifier based on or associated with the user input. For example, the ARS 604 may use a business identifier input by the user as the customer identifier or create a customer identifier and associate a business identifier (e.g., license number, registration number, tax identifier, etc.) input by the user with the customer number.

At 704, the ARS 604 confers or otherwise electronically consults digital rules (e.g., digital tax registration rules 570) to determine where and when to search for content (e.g., which local sources and/or databases and which remote sources such as public/government web sites 566) and what content to search for based on the customer number and/or business identifier. For example, if the business identifier is for a trade registration, the digital rules may indicate to search for trade registration documents at a particular government web site for registering such companies.

At 706, the ARS 604 searches for and fetches documents for tax registration from the local sources and/or databases determined by conferring the digital rules based on the customer number and/or business identifier.

At 708, the ARS 604 gathers data and/or documents for tax registration from the remote sources, such as public/government web sites 566, determined by conferring or otherwise electronically consulting the digital rules based on the customer number and/or business identifier (e.g., by using a webcrawler to access uploaded documents from remote sources and/or via an application programming interface (API)). The ARS 604 may also gather data and/or documents for tax registration from the user uploading applicable documents via the adaptive UI 540.

At 710, the ARS 604 extracts specific data from the fetched documents and the gathered and uploaded data and/or documents applicable for tax registration.

At 712, the ARS 604 presents the extracted data (e.g., via the adaptive UI 540) and verifies the extracted data to determine whether there is any data required for the tax registration that is missing (e.g., data may be missing, incorrect or not available on the documents discovered by or provided to the ARS 602).

At 714, if it is determined that there is data required for the tax registration that is missing, the method 700 proceeds to 716. If it is determined that there is no data required for the tax registration that is missing, the method 700 proceeds to 718.

At 716, the ARS 604 requests the missing data from the user (e.g., via the adaptive UI 540).

At 718, the ARS 604 updates the adaptive UI 540 to show the data is verified or receives the requested missing data if it was previously determined there was missing data and then updates the adaptive UI 540.

At 720, the ARS 604 generates the tax registration form based on the extracted and verified data and then sends the tax registration form (e.g., a VAT registration form) or a notification regarding the tax registration form to the user and/or a tax return generator, which may be part of the tax registration engine 583, for filing or further processing.

FIG. 8 is a flowchart for illustrating a sample method 800 for electronically generating a registration form for registering with a tax authority (e.g., VAT tax authority) or for filing a tax return according to another embodiment of the present disclosure.

At 802, the ARS 604 receives user input and defines that user input as a customer identifier or creates a customer identifier based on or associated with the user input. For example, the ARS 604 may use a business identifier input by the user as the customer identifier or create a customer identifier and associate a business identifier (e.g., license number, registration number, tax identifier, etc.) input by the user with the customer number.

At 804, the ARS 604 determines whether or not to fetch a document from a remote source (e.g., public/government web sites 566) based on the customer identifier and/or business identifier. For example, if it is known or otherwise determined that the business identifier is used by a particular public/government web site to identify the entity and access relevant document at that web site, then it may be determined to fetch an applicable document regarding that entity from that web site. In some embodiments, the ARS 604 determines what documents to target based on information already known associated with the customer identifier. In some embodiments, the Docufetch component 554 of the ARS 604 may use provided login credentials of the entity to do so in addition to using the business identifier. If it is determined to fetch a document, the method 800 proceeds to 808. If it is determined not to fetch a document, the method 800 proceeds to 806.

At 806, the ARS 604 confers or otherwise electronically consults digital rules (e.g., digital tax registration rules 570) to determine which local sources and/or databases (e.g., those local sources and/or databases of the OSP 598 and/or client device 593) to search for customer (i.e., client) user data and/or support content based on the customer number and/or business identifier and/or other data.

At 810, the ARS 604 receives the user data from local sources and/or databases of the OSP 598 and/or client device 593 based on the conferring or otherwise electronically consulting the digital rules, and may optionally update the adaptive UI 540 with data and/or status regarding the received user data.

At 814, the ARS 604 extracts specific data (e.g., business information, business identification information, transaction information, goods or services information, historical information, etc.) from the received user data applicable for tax registration.

At 818, the ARS 604 generates the tax registration form based on the extracted data and then sends the tax registration form (e.g., a VAT registration form) or a notification regarding the tax registration form to the user and/or a tax VAT return generator, which may be part of the tax registration engine 583, for filing or further processing.

At 808, the ARS 604 electronically gathers data and/or documents for tax registration from the remote sources such as public/government web sites 566 based on the customer number and/or business identifier (e.g., by using a webcrawler, accessing uploaded documents form remote sources and/or via an application programming interface (API) to the remote sources).

At 816, the ARS 604 receives the gathered data from the remote sources and may optionally update the adaptive UI 540 with data and/or status regarding the gathered data.

At 812, the ARS 604 confers or otherwise electronically consults digital rules (e.g., digital tax registration rules 570) to determine which specific data to extract from the gathered data and/or documents that is applicable for tax registration in specific tax jurisdictions for applicable tax authorities.

At 820, the ARS 604 extracts specific data from the gathered data and/or documents that is applicable for tax registration in specific tax jurisdictions for applicable tax authorities as determined by conferring the digital rules.

At 822, the ARS 604 generates the tax registration form based on the extracted data and then sends the tax registration form (e.g., a VAT registration form) or a notification regarding the tax registration form to the user and/or a tax return generator, which may be part of the tax registration engine 583, for filing or further processing. In some instances, the method 800 may proceed directly to 818 or 822 from 802 to generate the tax registration form if the applicable data has already been gathered and extracted for doing so or if an auto-verification and auto file configuration is be performed by the ARS 604. For example, the ARS 604 may generate the registration form and then generate the VAT return as a NIL filing (e.g., where the tax return is required but there is a zero monetary obligation, some jurisdictions require an entity to file even when nothing is owed).

In various embodiments, more than one iteration of conferring digital rules, fetching data, extracting, and verifying data may occur in order to collect the necessary customer data to generate an accurate registration form. In this spirit, it will also be appreciated that the adaptive UI 540 and/or content served to the customer may be updated and configured in a customized manner responsive to the iterations for collecting and requesting the necessary customer data to generate an accurate registration form. The registration form is generated by combining extracted data and customer data, and conferring the digital rules.

In some embodiments, once the registration form is generated and automatically filed with a respective tax authority, the ARS 604 is configured to capture or receive a confirmation notification, screen capture of the filing confirmation or a receipt, and store it in the system for proof of filing and serve to the customer (i.e., client) upon request.

In some embodiments, it will be appreciated that any component illustrated in FIG. 5 , FIG. 6 , FIG. 7 and FIG. 8 or the ARS 604 itself may be horizontally scalable by its implementation and architecture to increase the number of transactions, clients or throughput and perform such actions simultaneously and/or concurrently. The horizontal scalability of the system, represented by scalable resource return filing system 606 in FIG. 6 , enables the system to adjust for growth and increase the number of customers/users (i.e., client devices) who can be serviced at one time, thus improving the efficiency and speed of computer networks, ERP technology and digital technology. The computer system 595 may be configured to employ parallel processes for executing a large number of transactions for a large number of client devices for electronic filing of registrations, thus reducing the overall time the system takes to complete such computerized tasks and thereby improving the efficiency and speed of applicable computer networks, computerized automated enterprise resource planning (ERP) technology and networks, computer systems, devices, storage media and digital technology.

In some embodiments, customers may manually approve a registration form before filing, but in other embodiments, in an auto-approval service, the registration forms may undergo an automated verification process and automated filing by the ARS 604. In embodiments, an auto-verification and auto file configuration may be performed by the ARS 604. For example, as explained previously, the ARS 604 may generate the registration form and then generate the VAT return as a NIL filing (e.g., where the tax return is required but there is a zero monetary obligation, some jurisdictions require an entity to file even when nothing is owed).

In an example embodiment, possible initial user inputs to the ARS 604 include: the user configures ARS 604; the user configures extractors; the user verifies that data is correct; the user configures a remittance (e.g., with bank account, credit card, etc.). In some embodiments, the user never touches the ARS 604 service/products again after making one or more of such initial user inputs, but the ARS 604 automatically files registration forms to enable automated filing of tax related documents to external government agencies, such as VAT returns or other tax documents (i.e., “Zero Touch”) until or unless a substantive event occurs to the customer or business, e.g., a user enters another market (location or product or service), when there is a change in business/location, a change in law, etc. In such cases, the user provides changes and updates the configuration (e.g., via adaptive UI 540) before going “hands-off” again. In other embodiments, such updates and configurations are automatically detected and made by the ARS 604 such that the user may continue to go “hands-off”.

FIG. 9 is a flowchart for illustrating a sample method 900 for electronically generating and filing a tax return (e.g., VAT tax return) based on a registration form according to various embodiments of the present disclosure.

Once the registration form is automatically submitted to a tax authority, for example, a tax return may also be automatically prepared and the tax return automatically filed by, for example, by the tax registration engine 583 or a separate part of the OSP 598, which may also be managed by the WFaaS component 602. Once a tax return is filed, the customer may be notified and prompted to pay VAT tax. Other notifications may also be served to the customer (i.e., client), such as an electronic filing confirmation.

For example, at 902, the OSP 598 receives the tax registration form from the tax registration engine 583 (e.g., generated at 720 in method 700 or generated at 818 or at 822 in method 800).

At 904, the OSP 598 electronically consults the VAT digital rules (e.g., which may be part of the digital tax registration rules 570) to determine, based on the registration, how and when to generate the VAT return for specific applicable tax authorities 580, track and update the applicable user account, generate the applicable user notification to pay the VAT and, notify when the VAT return has been filed.

At 910, the OSP 598 electronically generates the VAT return based on the received registration form and the consultation of the VAT digital rules.

At 912, the OSP 598 electronically files the generated VAT return with the applicable tax authority (e.g., tax authority 581 or tax authority 582) based on the received registration form and the consultation of the VAT digital rules.

At 906, the OSP 598 generates the applicable user notification to pay the VAT and then notifies the user (e.g., via electronic message or updates to the applicable adaptive UI 540) when the VAT return has been filed.

At 908, the OSP 598 tracks and updates the applicable user account associated with client device 593 regarding filing of the generated VAT return with the applicable tax authority.

FIG. 10 is a flowchart for illustrating a sample method 1000 for electronically requesting and verifying missing data to generate a registration form for registering with a VAT tax authority or for filing a VAT tax return according to an embodiment of the present disclosure.

In various embodiments, digital verification rules (e.g., which may be part of the digital tax registration rules 570) may be electronically consulted to electronically verify trade registers, but also for other documents as well. Decisions may be made by the tax registration engine 583, for example, whether uploaded or fetched documents are clear and/or legible, whether the information extracted from various sources and documents matches other information the OSP 598 knows about that customer (i.e., client), and so on. As decisions are made and approvals received or rejected, the WFaaS 602 will adjust the workflow processes accordingly. In some embodiments, workflows may be bifurcated and/or processed in parallel based on those decisions.

For example, at 1002 the tax registration engine 583 extracts specific data from the fetched documents and the gathered and uploaded data and/or documents applicable for tax registration.

At 1004, the tax registration engine 583 presents (e.g., via the adaptive UI 540) and verifies the extracted data to determine whether there is any data required for the tax registration that is missing (e.g., data may be missing or not available on the documents discovered by or provided to the tax registration engine 583).

At 1006, if it is determined that there is data required for the tax registration that is missing, the method 1000 proceeds to 1008. If it is not determined that there is data required for the tax registration that is missing, the method 1000 proceeds to 1010 and/or 1012.

At 1008, the tax registration engine 583 receives missing data (e.g., via the adaptive UI 540) and may proceed again back to 1006 to determine whether there is any additional missing data and continue the process until it is determined there is no missing data.

At 1010, the tax registration engine 583 requests (e.g., via the adaptive UI 540) country specific data, if applicable (e.g., business licensure data for a specific country).

At 1012, the tax registration engine 583 requests (e.g., via the adaptive UI 540) data that is required due to other inputs. Such “other inputs” may refer to cases involving follow-up questions presented by the adaptive UI 540 that only apply if a customer gives a certain earlier answer. For example, such as whether the seller uses a fulfillment service, which service, and what countries they use that service in. Those responses could trigger or otherwise lead to additional follow up questions automatically presented via the adaptive UI 540.

At 1014, tax registration engine 583 optionally verifies any added data, whether that be any received missing data, any added country specific data and/or any added data that is required due to other inputs, as applicable. The tax registration engine 583 then provides such verified data for the generation of the tax registration form (e.g., provides such data to the form generator 558).

FIG. 11 is a sample view of a User Interface (UI) 1100 for OSP 598 utilizing a customer identifier in a process of generating a registration form for registering with a VAT tax authority or for filing a VAT tax return according to an embodiment of the present disclosure. In various example embodiments, UI 1100 may comprise or be part of the adaptive UI 540 and the description of UI 1100 will be in conjunction with also referring to FIG. 5 .

Shown is an example status bar 1116 that shows the user where the client is in the process of setting up and activating their client account on the OSP 598. Also shown is a company or incorporation number input field 1102, where a user may input a business identifier (company or incorporation number, etc.) associated with the client. For example, customer identifier 027152637 has been input, which may be used by the tax registration engine 583 to look up information about a customer or business (i.e., the client). Another input filed 1104 is also shown for inputting other relevant identification information. For example, a prompt 1106 is shown that prompts the user to enter the full legal name of the business.

Also shown are interactive UI elements such as a back button 1108 to proceed to a previous screen, a save and continue later button 1110 to save the user's progress in the account creation process to continue at a later time, and a continue button 1112 to continue to the next UI screen when such requested information has been input to the appliable input fields. Also shown is a customer assistance selectable UI element 1114 which the user may select to receive additional live assistance from a customer service representative or additional instruction and resources regarding the account creation and/or registration process.

For creating a customer identifier, a customer may use their business identifier (e.g., by inputting it into company or incorporation number input field 1102), which allows the system to know what business to search for to get their company documents. Company documents (i.e., business documents) may include business information, business licenses, Trade Registers, articles of incorporation, company owners and officers, address, location, and so on. It may be any business information in various different embodiments. In various example embodiments, the support content electronically collected by the OSP 598 (and OSP 198 of FIG. 1 ) may include such company documents and/or data contained in such documents.

In some embodiments, the customer identifier may be newly generated by OSP 598, and OSP 598 may associate one or more business identifiers (e.g., license number, registration number, tax identifier, etc.). The OSP 598 may generate an identifier having a set of identifiers or sub-identifiers associated with that OSP 598 generated customer identifier. Any one of the associated identifiers in the set could be searched on for gathering business information.

Business documents in different jurisdictions of the tax authorities 580 may vary. In embodiments, the ARS 604 is configured to make decisions based on digital rules (e.g., digital tax registration rules 570) to determine where and when to search for content and what content to search. Some of these decisions may be based on known information, and some may be determined based on events or findings by the ARS 604. In the adaptive UI 540 for the customer, a decision may be made by the registration engine 583 (e.g., by electronically consulting digital tax registration rules 570) to either ask the customer via the adaptive UI 540 to manually provide information or automatically interpret information, for example, based on their business number.

In an example embodiment, what the customer experiences via the adaptive UI 540 will vary, will be updated and may be customized based on the collected, known or processed data. For example, the UI 1100 may display the company or incorporation number input field 1102 and then, based on the particular company or incorporation number input into the company or incorporation number input field 1102, dynamically display the another input filed 1104 to collect further required business information based on and in response to a determination by the tax registration engine 583 (e.g., by consulting the digital tax registration rules 570) that the further required business information could not be interpreted from or otherwise collected based merely on the particular company or incorporation number previously input into the company or incorporation number input field 1102. This dynamic display related to the structure of the UI 1100, other UIs disclosed herein and adaptive UI 540 avoids the user interface having to needlessly display input fields and UI elements (e.g., the input filed 1104 to collect further required business information) when such information is able to be interpreted from the particular company or incorporation number previously input into the company or incorporation number input field 1102 (or from other information previously collected by the ARS 604 disclosed herein), thereby solving a technical problem in prior graphical user interface devices in the context of computerized tax registration and electronic document generation systems relating to speed, accuracy and usability, and thus improves such technology.

Digital tax registration rules 570 may include digital rules which are electronically consulted by the tax registration engine 583 to control applicable computer operations electronically executed by the tax registration engine 583. For example, tax registration engine 583 may electronically consult the digital tax registration rules 570 to recognize which tax jurisdiction is applicable based on the business number, validate the jurisdiction, and automatically pull electronic documents from that government website for that particular jurisdiction, which may be part of public/government web sites 566. This saves time of computing systems and reduces network traffic which would otherwise be used to instead electronically query and send network requests to each of multiple different server systems in order to pull multiple different data to locate the compatible and relevant data, thereby improving the operations of computers and computer networks.

FIG. 12 is a sample view of a UI 1200 for OSP 598 presented to a user for collecting further business information for generating a registration form for registering with a VAT tax authority or for filing a VAT tax return according to an embodiment of the present disclosure. In various example embodiments, UI 1200 may comprise or be part of the adaptive UI 540 and the description of UI 1200 will be in conjunction with also referring to FIG. 5 . In various example embodiments, UI 1200 may be used in conjunction with UI 1100 or may be used instead of UI 1100 to the extent it collects the same information as UI 1100.

UI 1200 includes an example questionnaire that may be presented to a user via the adaptive UI 540 to collect information such as that described herein for completing a registration form (e.g., a VAT certification tax registration form). Shown is a first UI section 1202 including input fields for the company or incorporation number, the primary business website or Uniform Resource Locator (URL), the business contact phone number, and WeChat ID. For example, the company or incorporation number may be a “SIREN” number (a French tax identification number), which translated into English stands for “Business Directory Identification System” and is a 9-digit identifier assigned to every registered business in France by the National Institute of Statistics and Economic Studies (INSEE). It is used to identify the business and its legal entity, such as a company or a sole proprietorship.

Interactive UI elements may also be provided by UI 1200 to collect other business information and contact information in various embodiments. For example, also shown in a second UI section 1204 prompting for whether the company has a tax number, a country of registration input filed 1206 and an effective date of registration input field 1208. Other or different input fields may be displayed to collect other relevant contact details and/or other relevant business information. Additionally, shown is a save and close button 1210 to save the user's progress in the current process to continue at a later time, and a save and continue button 1212 to continue to the next UI screen when such requested information has been input to the appliable input fields.

FIG. 13 is a sample view of a UI 1300 for OSP 598 presented to a user for indicating which tasks still need to be completed in a process for generating a registration form for registering with a VAT tax authority or for filing a VAT tax return according to an embodiment of the present disclosure. In various example embodiments, UI 1300 may comprise or be part of the adaptive UI 540 and the description of UI 1300 will be in conjunction with also referring to FIG. 5 .

An example of a data extraction process (e.g., which may be performed by information extractor 556) in an example embodiment of a process for generating a registration form for registering with a VAT tax authority is when a customer is requested by adaptive UI 540 for identification information for verification of their identity. UI 1300 shows the “Registrations tab” 1306 is currently selected to indicate to the customer that certain registration tasks still need to be completed, one of which includes uploading an identification document (e.g., a passport) to progress the registration process, which can be initiated by selecting UI element 1310.

Furthermore, in the present example, selectable UI element 1312 indicates further business information needs to be collected, which can be initiated by selecting UI element 1312. Also, selectable UI element 1314 indicates an application for Extended Producer Responsibility (EPR) taxation needs to be made, which can be initiated by selecting UI element 1314. User interface element 1316 may be selected to initiate the process for signing documents to complete the process for generating a registration form for registering with a VAT tax authority.

Also shown is a status section 1318 which displays the status of registration applications in various tax jurisdictions for a specific customer. For example, status notice 1320 indicates status of a “France Domestic Union—OSS” application and status notice 1322 indicates status of a “Spain Foreign VAT” application for the customer.

Also shown are example selectable tabs which may be selected to indicate to the customer that certain registration tasks still need to be completed for items related to the particular tab. In the present example, shown is a returns tab 1302 which may be selected to indicate to the customer that certain tasks related to tax returns still need to be completed. Also shown is a data tab 1304 which may be selected to indicate to the customer that certain tasks related to user or business data still need to be completed (e.g., collection and/or verification of such data). A settings tab 1308 is shown which may be selected to change various settings, configurations and/or preference related to the adaptive UI 540, user account and/or the tax registration services provided by OSP 598.

FIG. 14 is a sample view of a UI 1400 for OSP 598 presented to a user for verification of the user's identity in a process for generating a registration form for registering with a VAT tax authority or for filing a VAT tax return according to an embodiment of the present disclosure. In various example embodiments, UI 1400 may comprise or be part of the adaptive UI 540 and the description of UI 1400 will be in conjunction with also referring to FIG. 5 .

In an example embodiment, after the user selects UI element 1310 in UI 1300 shown in FIG. 13 to upload an identification document (e.g., a passport), the UI 1400 appears and asks the customer to upload the passport. The user then provides a scan of a passport. In particular, shown is UI prompt 1402 which prompts the user to start by uploading a passport below. Displayed below UI prompt 1402 is a selectable UI element 1404 which the user may select to initiate the process to upload an image of a passport or scan and upload an image of a passport. Also displayed is a back button 1406 which the user may select to go to a previous screen or step in the process, a save and continue later button 1408 to save the user's progress in the process to continue at a later time, and a continue button 1410 to continue to the next UI screen when the identification document (e.g., passport) has been properly uploaded.

FIG. 15 is a sample view of a UI 1500 for OSP 598 presented to a user showing an identification document uploaded by the user for verification of the user's identity in a process for generating a registration form for registering with a VAT tax authority or for filing a VAT tax return according to an embodiment of the present disclosure. In various example embodiments, UI 1500 may comprise or be part of the adaptive UI 540 and the description of UI 1500 will be in conjunction with also referring to FIG. 5 .

Shown displayed on UI 1500 is an image of an example scanned and uploaded identification document 1502 (e.g., a passport) resulting from the user following the process to do so initiated by selection of UI element 1404 on UI 1400 shown in FIG. 14 . In an example embodiment, if the scan of the identification document 1502 is blurry, illegible or otherwise deficient, OSP 598 detects the deficiency (e.g., by not being able to read the document) and prompts via UI 1500 for a new scan, and the feedback is provided in real time. OSP 598 will first resolve the deficiency issue to correctly identify the customer, before the UI 1500 updates with the next step of the registration process.

In another example, instead of a passport, an automatic download of a trade register fails, and the adaptive UI 540 is updated to prompt the customer with additional questions related to the trade register. The trade register may have been provided by the customer or it may have been downloaded as part of the process implemented by the Docufetch component 554. The updating of the adaptive UI 540 occurs in real time to request the information OSP 598 needs to proceed to the next step in the tax registration process. As the data is verified, the data is processed by the tax registration engine 583 for storage and to be later retrieved for generating the registration form by the form generator 558. The controls and instructions for this operation may be modified, configurable and regulated by the WFaaS component 602. Other documents may be processed and may in some instances comprise content that is electronically retrieved from websites as public information, such as from public/government web sites 566.

In an example embodiment, the digital tax registration rules 570 may be electronically consulted by the tax registration engine 583 to decide what the ARS 602 does next and how to update the adaptive UI 540. For example, the digital tax registration rules 570 being electronically consulted by the tax registration engine 583 may result in the following instructions being executed: first retrieve business document; then check/verify data about the customer based on the business document; and then check/verify customer data provided via adaptive UI 540 and existing customer data stored by the OSP 598. Each of the preceding steps may have a number of processes and flows before the next step is iterated, some or all of which may be modified, configured and regulated by the WFaaS component 602.

FIG. 16 is a sample view of a UI 1600 for OSP 598 presented to a user for indicating certain tasks have been completed in a process for generating a registration form for registering with a VAT tax authority or for filing a VAT tax return according to an embodiment of the present disclosure. In various example embodiments, UI 1600 may comprise or be part of the adaptive UI 540 and the description of UI 1600 will be in conjunction with also referring to FIG. 5 .

In an example embodiment, UI 1600 may appear or be made available (e.g., by selecting the “Registrations” tab) when the upload document task referenced by UI element 1310 of FIG. 13 , and for which an example is shown in UI 1500 of FIG. 15 , is complete. In particular, the UI element 1602 has been updated to show the upload document task has been completed (e.g., the user has successfully scanned and uploaded the required identification document). Also, the UI element 1604 has been updated to show the providing of business information task has been completed as well. Additionally, as also shown in UI 1300 of FIG. 13 , a status section on the lower half of the UI 1600 displays to the user the updated status of various applications for registration in various different jurisdictions and also displays selectable UI elements indicating whether actions are required for the user to complete for each.

FIG. 17 is a sample view of a UI 1700 for OSP 598 presented to a user for the user to verify extracted data in a process for generating a registration form for registering with a VAT tax authority or for filing a VAT tax return according to an embodiment of the present disclosure. In various example embodiments, UI 1700 may comprise or be part of the adaptive UI 540 and the description of UI 1700 will be in conjunction with also referring to FIG. 5 .

UI 1700 is an example of a user interface displaying content prepared by the OSP 598 before a registration form is generated. For example, the content displayed in UI 1700 may be that which was extracted by the information extractor 556 from one or more documents obtained by the Docufetch component 554 from external sources and/or one or more documents uploaded by the user via the adaptive UI 540. In the present example, shown is company information 1702 extracted from a business registration form either uploaded by the user or obtained by the Docufetch component 554 from a particular public web site of the public/government web sites 566 based on the business identifier input by the user to input field 1102 of UI 1100 shown in FIG. 11 . Shown is selectable UI element 1704 which the user may select to edit or add to the company information 1702.

Also shown is directors information section 1706, which displays director information extracted from a business registration form either uploaded by the user or obtained by the Docufetch component 554 from a particular public web site of the public/government web sites 566 based on the business identifier input by the user to input field 1102 of UI 1100 shown in FIG. 11 . Shown is selectable UI element 1708 which the user may select to edit or add to the information displayed in the directors information section 1706.

Also shown are interactive UI elements such as a back button 1710 to proceed to a previous screen or step in the process, a save and continue later button 1712 to save the user's progress in the process to continue at a later time, and a documents signing button 1714 to initiate a UI driven process for the user to sign documents based on the displayed content being verified by the user as correct.

FIG. 18 is a sample view of a UI 1800 for the OSP 598 presented to a user for electronically completing a power of attorney (POA) in a process for generating a registration form for registering with a VAT tax authority or for filing a VAT tax return according to an embodiment of the present disclosure. In various example embodiments, UI 1800 may comprise or be part of the adaptive UI 540 and the description of UI 1800 will be in conjunction with also referring to FIG. 5 .

The UI 1800 may appear or be made available by the tax registration engine 583 in response to or otherwise based on the user selecting to sign documents to progress in completion of the process for generating a registration form for registering with a VAT tax authority or for filing a VAT tax return. For example, such selection may be made by the user selecting the documents signing button 1714 in the UI 1700 of FIG. 17 , by selecting the sign your documents UI element 1316 in UI 1300 of FIG. 13 or selecting another selectable UI element of the adaptive UI 540 for signing documents. For example, the tax registration engine 583 may automatically electronically generate documents needed for signature to complete the registration process, such powers of attorney and/or other relevant documents using data input by the user and/or extracted by the Docufetch component 554. UI 1800 is an example of a UI which may be presented to the customer/user for electronically completing a POA to progress in completion of the process for generating a registration form for registering with a VAT tax authority or for filing a VAT tax return.

Shown in UI 1800 is UI section 1820 which may display the business name and other relevant company information of the company providing the POA, such as the company name “Supercell Oy”, country of origin, etc. Also displayed is selectable element 1808 which the user may select in order to proceed to a seller page with further information regarding the seller. Selectable element 1810 is displayed which the user may select to proceed to a notes UI into which the user may enter notes. Selectable element 1812 is also displayed which the user may select to proceed to a documents page where the user can see and select various documents related to the process for generating a registration form for registering with a VAT tax authority or for filing a VAT tax return. UI section 1802 displays a current registration application number for which a POA is being generated and other application information.

Selectable element 1822 represents a particular POA of a possible plurality of POAs (in progress or completed) from which to select. Selectable element 1822 is selectable to display in UI 1800 the particular POA 1806 which selectable element 1822 represents and also displays a current status of the currently selected and displayed POA 1806. UI section 1804 provides various selectable document navigation and viewing options to navigate through and view displayed POA 1806, as well as to upload and download POA 1806. Displayed POA 1806 may also include an instruction page including instructions for the user for how to complete the POA using by using UI 1800. A “Review Power of Attorney” section of UI 1800 may include a business information user input section 1816 which includes input fields in one consolidated section of the UI 1800 for the user to input text for particular business information items which the user needs to fill in, which may also be highlighted for the user within displayed POA 1806. The “Review Power of Attorney” section of UI 1800 may also include a legal representatives user input section 1818 which includes input fields in one consolidated section of the UI 1800 for the user to input text to indicate the legal representative(s) to which the POA 1806 is being granted, which the user may need to fill in and may also be highlighted for the user within the displayed POA 1806. In an example embodiment, the user may select the “Complete” UI element 1814 once the required data is entered via UI 1800 for the POA in order to initiate a process of signing the POA.

FIG. 19 is a sample view of a UI 1900 for the OSP 598 presented to a user for electronically downloading documents and then uploading signed documents, such as a power of attorney, in a process for generating a registration form for registering with a VAT tax authority or for filing a VAT tax return according to an embodiment of the present disclosure. In various example embodiments, UI 1900 may comprise or be part of the adaptive UI 540 and the description of UI 1900 will be in conjunction with also referring to FIG. 5 .

If an automated process as described above fails or is determined to not exist for the above tasks, then the process may proceed instead to collect such information or collect such documentation by input or document upload via adaptive UI 540 prompting a user to do so. In cases where an electronic signature is acceptable for registration or signing documents required or associated with registration, the process may proceed to generate a signature link for such signatures and communicating such to the user. Otherwise, such documents are provided electronically to the user with instructions, such as instructions 1902, for how to sign and provide such signed documents back to OSP 598.

In particular, UI 1900 is an example UI enabling a user to download the relevant generated document for signature, having the document signed by a legal representative of the applicable company, scanning the signed document and then uploading the signed document to the OSP 598, such that the registration process may continue. In one embodiment, UI 1800 may appear as a result of the user selecting the “Complete” UI element in UI 1800 of FIG. 8 to complete the process of signing the POA. In addition to displaying instructions 1902 for how to sign and provide such signed documents back to OSP 598, UI 1900 includes a selectable document download element 1904 which the user may select to download the document to sign. Also, included are upload instructions 1906 for the user to upload the signed document and/or other supporting or relevant documents (e.g., an identification document). UI element 1908 may be selected to enable browsing for the document on one's computer to upload or the user may drag and drop a document to the UI element 1908 to upload it. Also displayed is a save and close button 1910 for the user to save their progress in the process and close UI 1900.

FIG. 20 is a sample view of a UI 2000 for the OSP 598 presented to a user when an uploaded image is not clear, such as that of a power of attorney or identification document, in a process for generating a registration form for registering with a VAT tax authority or for filing a VAT tax return according to an embodiment of the present disclosure. In various example embodiments, UI 2000 may comprise or be part of the adaptive UI 540 and the description of UI 2000 will be in conjunction with also referring to FIG. 5 .

In an example embodiment, UI 2000 may be displayed in response to or otherwise based on the user uploading a document via UI element 1310 of UI 1300, UI element 1404 of UI 1400, UI element 1602 of UI 1600 or UI element 1908 of UI 1900. In the present example, the tax registration engine 583 (e.g., the information extractor 556) recognized or otherwise detected the uploaded document was unclear, illegible, unreadable or did not meet a particular quality standard. In particular, in response to this detection, a “Failed” notice 2002 is displayed on UI 2000 indicating the uploaded document is not able to be clearly read. A selectable UI element 2006 is displayed for the user to select to re-upload the document, such that a clear image is obtained. The uploaded document 2004 is displayed and a selectable UI element 2008 is also displayed which the user may select to remove the document before uploading it again.

FIG. 21 is a sample view of a UI 2100 for the OSP 598 presented to a user when an uploaded image is clear, such as that of a power of attorney or identification document, in a process for generating a registration form for registering with a VAT tax authority or for filing a VAT tax return according to an embodiment of the present disclosure. In various example embodiments, UI 2100 may comprise or be part of the adaptive UI 540 and the description of UI 2000 will be in conjunction with also referring to FIG. 5 .

In an example embodiment, UI 2100 may be displayed, for example, displayed in response to or otherwise based on the user uploading a document via UI element 1310 of UI 1300, UI element 1404 of UI 1400, UI element 1602 of UI 1600 or UI element 1908 of UI 1900, or re-uploading a document via UI element 2006 if UI 2000. In the present example, the tax registration engine 583 (e.g., the information extractor 556) recognized or otherwise detected the uploaded document is clear, readable, such as to meet a particular quality standard. The uploaded document 2102 is displayed for visual inspection by the user. A save and close button 2104 is also displayed, which the user may select to save the current progress of the user in the process for generating a registration form for registering with a VAT tax authority or for filing a VAT tax return and to close the UI 2100.

FIG. 22 is a sample view of a UI 2200 for the OSP 598 presented to the user indicating the status of signatures needed in each different jurisdiction for which registration is being applied, in a process for generating a registration form for registering with a VAT tax authority or for filing a VAT tax return according to an embodiment of the present disclosure. In various example embodiments, UI 2200 may comprise or be part of the adaptive UI 540 and the description of UI 2200 will be in conjunction with also referring to FIG. 5 .

UI 2200 may be presented to the user indicating the status of signatures needed in each different jurisdiction for which registration is being applied and whether a wet signature is required or electronic signature is available. A selectable UI element associated with each status indication on the UI 2200 may be selected by the user to perform the electronic signature or receive instructions for performing the wet signature. In an example embodiment, UI 2200 may be displayed in response to or based on the user selecting the documents signing button 1714 in UI 1700 of FIG. 17 , by selecting the sign your documents UI element 1316 in UI 1300 of FIG. 13 or selecting another selectable UI element of the adaptive UI 540 for signing documents.

In the present example, selectable UI element 2202 is displayed indicating the signatures needed for registration in Germany are complete. Selectable UI element 2208 may be selected, for example, to view and/or download such signed documents and signatures and/or perform other processes and tasks related to such signed documents and signatures.

Selectable UI element 2204 is displayed indicating one or more signatures are still needed for registration in the UK, and that such documents may be digitally signed. Selectable UI element 2210 may be selected, for example, for the user to digitally sign such documents and/or perform other processes and tasks related to such documents and signatures needed.

Selectable UI element 2206 is also displayed indicating one or more signatures are still needed for registration in France and that a wet signature is required. Selectable UI element 2212 may be selected for the user to download, edit, sign, scan and/or upload such signed documents and/or perform other processes and tasks related to such documents and signatures needed for registration in France. For example, selection of UI element 2206 may cause one or more UIs, such as UI 1400, UI 1500, UI 1700, UI 1800, UI 1900, UI 2000 and/or UI 2100 to be displayed for completion of signing documents and/or providing signatures still needed for registration in France.

FIG. 23 is a sample view of an example UI screen 2300 of the OSP internal adaptive UI 569 for processing registrations for registering with a VAT tax authority or for filing a VAT tax return according to an embodiment of the present disclosure. In various example embodiments, UI 2300 may comprise or be part of OSP internal adaptive UI 569 shown in FIG. 5 and the description of UI 2300 will be in conjunction with also referring to FIG. 5 and FIG. 6 .

In an example embodiment, UI 2300 may be displayed to and used internally by administrators of the OSP 598 for processing and tracking registrations, such as VAT registrations, as well as for configuring the WFaaS component 602 in order to control the workflows of the ARS 604 to manage the data collected, generated, and processed, and to manage the process for generating a registration form.

As shown in UI 2300, displayed is a list of internal tasks 2316 that are to be performed in order to move registrations forward. The tasks may be driven by the WFaaS component 602. Shown in the list of internal tasks 2316 are some tasks ready to be performed in order to review registration documents the system has generated for the customer to sign and for the OSP 598 to submit to the applicable tax authority system. The administrator or agent user may select a displayed task in the list of internal tasks 2316 to view more detail regarding that task, claim that task, change a status of the task, modify the task and/or modify a workflow regarding that task or corresponding registration.

Displayed above the list of internal tasks 2316 are various filters that may be applied to select registration tasks having certain characteristics related to the corresponding registration or task. In particular, displayed are user input fields or menus to filter registration tasks based on seller name 2302, external reference ID 2304, task type 2306, associated jurisdiction 2308, source 2310, action 2312 and country of origin 2314. Also displayed is a selectable UI element 2318 to apply the selected filters to view the resulting filtered tasks and a selectable UI element 2320 to clear the filter selections.

FIG. 24 is a block diagram showing a system 2400 for generating a registration form for registering with a VAT tax authority or for filing a VAT tax return and for filing VAT tax returns according to an embodiment of the present disclosure. For example, the system 2400 may comprise, be part of or be included in, or in various respects be a higher or lower level view of, various components of the OSP 598 of FIG. 5 and/or ARS 604 of FIG. 6 . Thus, the description of system 2400 will be in conjunction with also referring to FIG. 5 and FIG. 6 .

Shown is a registration processing component 2402 which performs various tasks, steps and/or operations of registration as disclosed herein and may include the computer system 595 of FIG. 5 and/or components thereof, such as the tax registration engine 583 and/or components thereof. In an example embodiment, the registration processing component 2402 includes a gather preliminary data component 2404 and an assemble registration packet component 2410.

The registration processing component 2402 includes a gather preliminary data component 2404 which performs various tasks, steps and/or operations of gathering and collecting data as disclosed herein (e.g., such as those of the identifier component 552, the Docufetch component 554 and/or the information extractor component 556 of FIG. 5 ). The gather preliminary data component 2404 includes a receive data component 2406 which performs various tasks, steps and/or operations of receiving data disclosed herein (e.g., such as those of the identifier component 552 and the Docufetch component 554 and those described herein with respect to various UIs of FIG. 11 through FIG. 22 ). The gather preliminary data component 2404 also includes an auto review component 2408, which performs various tasks, steps and/or operations of automatically reviewing and verifying (or automatically displaying for visual verification) gathered and collected data as disclosed herein (e.g., such as those of information extractor 556 and those described herein with respect to detecting missing and/or incorrect data and reviewing uploaded documents).

The assemble registration packet component 2410 performs various tasks, steps and/or operations of assembling the registration packet for particular tax jurisdictions including generating the registration form using the reviewed data received from the gather preliminary data component 2404 (e.g., such as those of the form generator 558 of FIG. 5 ). The assemble registration packet component 2410 includes an organize data component 2412 that organizes data for including it on the registration form and otherwise formatting it in a customized manner for submission to a system of a particular tax jurisdiction according to that particular tax jurisdiction's system requirements. The assemble registration packet component 2410 also includes a prepare documents to submit component 2416 that prepares the applicable documents, such as the registration form and supporting documents, such as identification documents and/or POAs, for electronic submission to a system of a particular tax jurisdiction according to that particular tax jurisdiction system requirements. The assemble registration packet component 2410 also includes a resolve missing parts component 2418 which resolves (e.g., obtains) missing or incomplete data and/or forms according to the articular tax jurisdiction's system requirements, which may be detected and/or resolved at the stage of assembling the registration packet.

The system 2400 also includes a submit registration packet component 2420 that, once the registration packet has been properly assembled by the assemble registration packet component 2410, electronically submits the registration packet with the applicable tax jurisdiction system of various tax authorities 2424. The submit registration packet component 2420 may also submit the registration packet to a ready filings onboarding component 2422. The ready filings onboarding component 2422 may automatically prepare a corresponding tax return document or data according to requirements of the applicable tax jurisdiction system of the various tax authorities 2424 and then electronically communicate with the applicable tax jurisdiction to electronically file the tax return at the appropriate time with a system of applicable tax jurisdiction according to requirements of the applicable tax jurisdiction.

FIGS. 25A through 25D comprise a swimlane diagram 2500 including a flowchart for illustrating which system component may perform different operations in a sample process for electronically generating a registration form for registering with a VAT tax authority or for filing a VAT tax return according to an embodiment of the present disclosure.

In various example embodiments, the operations described with respect to swimlane diagram 2500 may be performed by one or more components of the ARS 604 depicted in FIG. 5 and FIG. 6 , the OSP 598 depicted in FIG. 5 and/or the system 2400 for generating a registration form depicted in FIG. 24 , and/or various applicable components thereof. Thus, the customer support/comms component, the customer UI component, the back-end automation component and the internal UI component corresponding to the various lanes of swimlane diagram 2500 may be implemented by or correspond to applicable components of the ARS 604 depicted in FIG. 5 and FIG. 6 , the OSP 598 depicted in FIG. 5 and/or the system 2400 for generating a registration form depicted in FIG. 24 , and/or various applicable components thereof. Accordingly, the description of the operations of swimlane diagram 2500 will be in conjunction with also referring to FIG. 5 , FIG. 6 and/or FIG. 24 .

At 2502, various applicable data about the customer and business has been passed to the tax registration engine 583 resulting from an online purchase (i.e., online “buy” of services of the OSP 598) and/or via other activities the customer has had with the OSP 598 and/or services provided by the OSP 598, such as a VAT checker service, OSP 598 account creation, other tax compliance services, etc. A questionnaire is thus presented via the customer UI for preparing the tax registration that has fewer questions than would have otherwise been presented if such data had not been passed to the tax registration engine 583, thereby increasing efficiency of the system.

At 2504, a document upload task for an identification document (e.g., a passport) is initiated via the customer UI, such as via adaptive UI 540. The back-end automation component (e.g., the information extractor 556) performs an automated review of the uploaded identification document and an OCR process on the document. For example, at 2506 the automated review may include a determination of whether there is at least an 80% confidence that the document is valid and usable data is extracted from the document.

At 2508, in the internal UI (e.g., in the OSP internal adaptive UI 569) the customer data and documents are visible in a license console UI from the time the order or registration process is begun, even if there is no action to be taken. The administrator user or other agent of the OSP 598 may edit customer information and documents to handle escalation of registration issues in the internal UI.

At 2510 it is determined whether the document passed an automated review performed at 2506. If the document did not pass automated review (e.g., there was no real-time rejection of the document) then the document upload task remains open and the process proceeds back to 2504 for the user to re-upload the document.

In an example embodiment, the user may upload their passport or other relevant document as described herein via the UI and the back-end automation of the OSP 598 may then automatically electronically review and extract information from the passport image relevant for completing the registration process (e.g., using automated OCR processes). The customer data and documents are visible via the OSP 598 internal UI (e.g., in the OSP internal adaptive UI 569) during the registration process. Such customer data and documents are also editable and able to be managed via the OSP internal UI to handle escalations and otherwise facilitate the registration process. If the document passes auto-review and the questionnaire is complete, the process proceeds to 2516 shown in FIG. 25B.

At 2516, for example, an automated pull of the business' Articles of Incorporation and Trade Register from various applicable public/government web sites 566 is performed. There may be separate such automations (which may be performed simultaneously or concurrently) for different sellers (e.g., for “X” and “Y” sellers) to thus improve speed of automated document registration and electronic document generation technology and computer networks for multiple systems of multiple sellers that are part of the network, thereby improving such technologies.

In an example embodiment, the OSP 598 automatically pulls, via the back-end automation, relevant documents from external web sites and/or data sources relevant to the registration process (e.g., Articles of Association, a Trade Register document and/or other data) using or otherwise based on identifying information and/or other information provided via the questionnaire and/or relevant uploaded documents (e.g., a passport or other identification document).

At 2518, an artificial intelligence/machine learning (AI/ML) process may also be used by OSP 598, via the back-end automation, to facilitate the registration process by detecting missing customer information and automatically completing such missing information that is useful for the registration process. For example, the AI/ML system may be trained using training data including example complete documents and data for the registration process labeled as such and/or use training data including example incomplete documents and data for the registration process labeled as such to learn to recognize complete and incomplete documents and data for the registration process. If the automation described above fails or doesn't exist, at 2530 the administrator (e.g., an agent of the OSP 598) may use the OSP 598 internal UI to perform the document upload and perform entry of the applicable data via the OSP 598 internal UI.

At 2520 the OSP 598, via the back-end automation, automatically electronically generates documents needed for signature to complete the registration process, such a powers of attorney (POA) and/or other relevant documents. An example of a UI presented to the customer/user for electronically completing the power of attorney is shown in FIG. 18 as UI 1800. If an automated process for generating documents needed for signature to complete the registration process as described above fails, or is determined to not exist for the above tasks, then the process may proceed instead to 2532 to collect such information or collect such documentation by input or document upload via a UI, and is shown as an open incomplete document generation task or a form generation review task in the OSP 598 internal UI. In an example embodiment, at 2524 such a form generation review task is not shown in the OSP 598 internal UI unless there was a failure in the automated process for generating documents needed for signature to complete the registration process.

At 2522, in cases where an electronic signature is acceptable for registration, the back-end automation of the OSP 598 proceeds to generate a signature link for such signatures on applicable documents, communicates such to the user and provides an alarm or other alert via the customer UI if the electronic signature process fails.

Otherwise, if an electronic signature is not acceptable for registration, at 2512 such documents are provided electronically to the user via the customer UI (e.g., via adaptive UI 540) with instructions for how to download, scan, sign and provide such signed documents back to the OSP 598. For example, UI 1800 of FIG. 18 , UI 1900 of FIG. 19 , UI 2000 of FIG. 20 and UI 2100 of FIG. 21 are example user interfaces enabling a user to download the relevant generated document for signature, have the document signed by a legal representative of the applicable company, scan the signed document and then upload the signed document to the OSP 598, such that the registration process may continue. UI 2000 illustrates an example UI presented when the uploaded image is not clear and provides a selectable UI element 2006 for the user to select to re-upload the document, such that a clear image is obtained, such as shown in UI 2100. In an example embodiment, at 2514 there is no separate review and rejection process for signatures. However, in other embodiments, there may be such a process.

After such signatures are obtained either at 2522 or 2512, the OSP 598 may also, in parallel with the registration packet generation at 2536 shown in FIG. 25C, perform various “Know Your Customer” (KYC) checks at 2528 on the information provided by the user and automatically collected from gathered documents, and then determine whether the KYC checks passed or failed and provide applicable notifications regarding pass-fail at 2534 via the internal UI. In the present example embodiment, at 2526 the KYC process does not block submission of the documents and data for the registration packet generation at 2536. However, at 2542, an exception handling process may be provided by the internal UI if there is an issue resulting from the KYC checks.

In response to such signatures being obtained at 2512, at 2536 the OSP 598 electronically generates a final submission packet ready to print as a single file and a packet quality review is performed electronically at 2540. Also, at 2544 the percentage of packets successfully passing quality review on the first attempt may be a key performance indicator (KPI) tracked by the OSP 598.

In response to the generated packet passing packet quality review at 2540, the OSP 598 may determine at 2538 whether there are any language translations required. If so, then at 2546 the packet is automatically translated or sent for translation, such as by the translator 568 shown in FIG. 5 . Otherwise, the process may proceed to 2550 in FIG. 25D. The date the packet was sent for translation and any translation notes may be recorded and associated with a translation task for display in the internal UI or it may be noted in the translation task that no translation is needed, and the task may be closed. At 2548, the OSP 598 may receive the translation and a translation task in the internal UI may be updated as a result by the system recording the date the translation was received and uploading the translation.

In response to the translation being completed, at 2550 shown in FIG. 25D, the OSP 598 determines whether the generated packet may be automatically submitted to the system of the applicable registration authority (e.g., to the system of a tax authority in the set of tax authorities 580). If the OSP 598 determines that the packet may be automatically submitted to the system of the applicable registration authority, the OSP 598 at 2552 automatically submits the packet to the system of the applicable registration authority electronically. Otherwise, at 2554 the process may automatically trigger initiation of a task of manual or non-electronic submission of the packet to the applicable registration authority via the internal UI. Also, in response to the automatic submission failing at 2552, the OSP 598 may also then at 2554 automatically trigger initiation of a task of manual or non-electronic submission of the packet to the applicable registration authority via the internal UI.

After the OSP 598 receives the registration certificate (e.g., VAT Certificate) back from the applicable registration authority, at 2556 the OSP 598 then records applicable details in a tax compliance task that may be displayed in the internal UI. Such details may include tax amounts due and/or other details regarding electronic filing a tax return or other compliance requirements. At 2558 The OSP then performs a confirm filings task, or opens such a task for display in the internal UI as needing to be completed, to confirm and record various registration data and tasks have completed correctly. The OSP 598 may also transmit or surface various applicable notices regarding the completion of the registration and applicable certificate to the agent of the OSP 598 via the internal UI and/or to the customer/user via the customer UI or via other electronic communications.

The embodiments described above may also use synchronous or asynchronous client-server computing techniques, including software-as-a-service (SaaS) techniques. However, the various components may be implemented using more monolithic programming techniques as well, for example, as an executable running on a single CPU computer system, or alternatively decomposed using a variety of structuring techniques known in the art, including but not limited to, multiprogramming, multithreading, client-server, or peer-to-peer, a microservice architecture, running on one or more computer systems each having one or more CPUs. Some embodiments may execute concurrently and asynchronously, and communicate using message passing techniques. Equivalent synchronous embodiments are also supported. Also, other functions could be implemented and/or performed by each component/module, and in different orders, and by different components/modules, yet still achieve the functions of the systems and methods described herein.

In addition, programming interfaces to the data stored as part of the system controller 210 and other system components described herein may be available by mechanisms such as through C, C++, C #, Python and Java APIs; libraries for accessing files, databases, or other data repositories; through scripting languages such as JavaScript and VB Script; or through Web servers, FTP servers, or other types of servers providing access to stored data. The databases described herein and other system components may be implemented by using one or more database systems, file systems, or any other technique for storing such information, or any combination of the above, including implementations using distributed computing techniques.

Different configurations and locations of programs and data are contemplated for use with techniques described herein. A variety of distributed computing techniques are appropriate for implementing the components of the embodiments in a distributed manner including but not limited to TCP/IP sockets, RPC, RMI, HTTP, RESTful (REST) APIs, Web Services (XML-RPC, JAX-RPC, SOAP, and the like). Other variations are possible. Also, other functionality may be provided by each component/module, or existing functionality could be distributed amongst the components/modules in different ways, yet still achieve the functions described herein.

Where a phrase similar to “at least one of A, B, or C,” “at least one of A, B, and C,” “one or more A, B, or C,” or “one or more of A, B, and C” is used, it is intended that the phrase be interpreted to mean that A alone may be present in an embodiment, B alone may be present in an embodiment, C alone may be present in an embodiment, or that any combination of the elements A, B and C may be present in a single embodiment; for example, A and B, A and C, B and C, or A and B and C.

As used herein, the term “or” may be construed in either an inclusive or exclusive sense. Moreover, plural instances may be provided for resources, operations, or structures described herein as a single instance. Additionally, particular operations are illustrated in a context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within a scope of various embodiments of the present disclosure. In general, structures and functionality presented as separate resources in the example configurations may be implemented as a combined structure or resource. Similarly, structures and functionality presented as a single resource may be implemented as separate resources. These and other variations, modifications, additions, and improvements fall within a scope of embodiments of the present disclosure as represented by the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

The various embodiments described above can be combined to provide further embodiments. These and other changes can be made to the embodiments in light of the above-detailed description. In general, in the following claims, the terms used should not be construed to limit the claims to the specific embodiments disclosed in the specification and the claims, but should be construed to include all possible embodiments along with the full scope of equivalents to which such claims are entitled. Accordingly, the claims are not limited by the disclosure. 

1. A method, including: electronically initiating a process to collect data via a graphical user interface (GUI) to facilitate automated preparation of an electronic registration before initiating a process to remit resources from a first entity to one or more recipient entities based on relationship instances between the first entity and a plurality of secondary entities; electronically obtaining a pre-existing entity identifier that had been previously used by an electronic system of at least one authority entity to identify the first entity; electronically establishing the pre-existing entity identifier to be associated with the first entity; using at least the entity identifier, performing automated actions to electronically collect one or more support content from the Internet regarding the first entity to facilitate automated preparation of the electronic registration document; electronically identifying data from the one or more support content relevant to the electronic registration; electronically extracting the identified data from the one or more support content in response to the electronically identifying the data; electronically verifying the extracted data; and electronically generating the electronic registration based on the extracted data.
 2. The method of claim 1, in which the operations further include: before electronically generating the electronic registration based on the extracted data, electronically determining, based on the extracted data, whether to electronically present a query via the GUI for supplemental data regarding the first entity to facilitate automated preparation of the electronic registration; automatically modifying the GUI in response to the determination whether to electronically present a query via the GUI for the supplemental data; electronically presenting the query via the GUI for the supplemental data; electronically receiving the supplemental data via the GUI in response to electronically presenting the query via the GUI for the supplemental data; and electronically verifying the supplemental data.
 3. The method of claim 2 in which the electronically generating the electronic registration is based on the extracted data and the supplemental data.
 4. The method of claim 2 in which the supplemental data includes one or more of: registration information regarding the first entity; information regarding the first entity stored by the at least one authority entity; information regarding the first entity available from public records identified using the entity identifier; information regarding the relationship instances between the first entity and a plurality of secondary entities; identification information regarding the first entity; location of the first entity; address of the first entity; name of individual associated with the first entity; products provided by the first entity; and services provided by the first entity.
 5. The method of claim 1 in which the at least one authority entity is the one or more recipient entities.
 6. The method of claim 1 in which the one or more support content includes one or more electronic documents.
 7. The method of claim 6 in which: the electronically identifying data from the one or more support content relevant to the electronic registration includes electronically reading the one or more electronic documents to identify data relevant to the electronic registration in the one or more electronic documents; and the electronically extracting the identified data from the one or more support content in response to the electronically identifying the data includes electronically extracting the identified data from the one or more electronic documents.
 8. The method of claim 1, in which the operations further include: based on the entity identifier, electronically determining whether to electronically present a query via the GUI for additional data to electronically collect information regarding the first entity to facilitate automated preparation of the electronic registration; automatically modifying the GUI in response to the determination whether to electronically present the query via the GUI for the additional data; electronically presenting the query via the GUI for the for additional data; and receiving the additional data in response to the query, in which the electronically generating the electronic registration is also based on the additional data.
 9. The method of claim 8 in which the additional data includes information to facilitate locating the additional data.
 10. The method of claim 8 in which the determining whether to present the query for additional data is based on a determination whether the additional data may be obtained using the entity identifier alone.
 11. The method of claim 1 in which the performing the automated actions to electronically collect one or more support content includes: using the entity identifier to identify which recipient entity of the one or more recipient entities and which digital rules associated with the identified recipient entity to use to determine locations of relevant support content for generating the electronic registration.
 12. The method of claim 11 in which the locations of relevant support content include one or more of: one or more web sites; one or more data servers; one or more data streams.
 13. The method of claim 1 in which the electronically identifying data from the one or more support content relevant to the electronic registration includes: using the entity identifier to identify which recipient entity of the one or more recipient entities and which digital rules associated with the identified recipient entity to use to determine which data is relevant from the one or more support content for generating the electronic registration.
 14. The method of claim 1 in which the electronically generating the electronic registration based on the extracted data includes: using the entity identifier to identify which recipient entity of the one or more recipient entities and which digital rules associated with the identified recipient entity to use to generate the electronic registration.
 15. The method of claim 1 further comprising: electronically receiving digital registration rules via the GUI; and automatically modifying the GUI according to the received digital registration rules to collect additional data via the GUI, in which the performing automated actions to electronically collect one or more support content from the Internet regarding the first entity to facilitate automated preparation of the electronic registration document is also based on the additional data.
 16. The method of claim 1 in which the electronically obtaining a pre-existing entity identifier includes: receiving an electronic document submitted via the GUI; extracting the entity identifier from the electronic document submitted via the GUI.
 17. The method of claim 1 in which the electronically obtaining a pre-existing entity identifier includes: presenting a prompt via the GUI for the entity identifier and a field into which the entity identifier is able to be entered; and receiving the entity identifier via the GUI from the field into which the entity identifier was entered.
 18. The method of claim 1 further including: generating a customer identifier based on the pre-existing entity identifier to identify the first entity within a system that generates the electronic registration.
 19. The method of claim 1 in which the generating the electronic registration includes: using a form generator to collate at least some the extracted data to electronically generate an electronic registration form according to digital rules which are based on requirements of a selected one of the one or more recipient entities to which the registration form will be sent.
 20. The method of claim 1 in which the automated actions include using a web crawler to go to public web sites to collect the one or more support content.
 21. The method of claim 1 in which the generating the electronic registration is also based on existing data regarding the first entity already stored within a system that generates the electronic registration resulting from providing past electronic services calculating or remitting resources from the first entity to one or more recipient entities.
 22. The method of claim 1 further including: presenting, via the GUI, a status of the electronic registration for each different recipient for which electronic registration is being performed for the first entity.
 23. The method of claim 22 in which the status is regarding one or more of: electronic signatures associated with the first entity needed from the first entity to complete registration and translations needed from the first entity to complete registration. 24-69. (canceled) 